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ABSTRACT 



The 


INTEL 


432/670 


microcomputer system 


contains 


the 


iAPX-432 


mlcroproces 


sor which executes 


compiled 


ADA 


proarams 


, The 


compiler 


resides on a host VAX 


11/780. 


and 



ccnplled proarams are downloaded to an INTEL MDS 800 system 
where they are transferred to the 432/670 for execution. 
This thesis describes a preliminary performance evaluation 
of the INTEL 432/670 through the use of selected benchmark 
algorithms from the Comouter Family Architecture (CFA) 
study, A description of the hardware components of both the 
MDS 000 and 432/670 is Provided. Including the modifications 
made to the operating system to allow compatibility with 
existing hardware. Additionally, the benchmark program 
source code and a user's manual are appended. 
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I. INTRODUCTION 



A, THESIS DESCRIPTION 

The development of new engineering tools is accompanied 
by the perceived need to find applications for those tools. 
Microprocessors are no exception. When a new computer is 
Introduced it is Important to know what, if any, significant 
benefits can be realized through its use. Things to consider 
in evaluating a microprocessor include several quantitative 
items, such as, instruction execution speed, memory 
capacity, and overall performance. Less tangible, hut 
equally important qualities of multiprocessor support, user 
protection, and ease of programming also need to be 
measured. The introduction of the INTEL lAPX-432 in 1981 
represented a radical change from traditional computer 
architectures. Previous advances in integrated circuits 
have primarily focused on larger memory, and faster 
execution. The lAPX-432 has addressed these issues, but has 
also tackled manv of the problems found in software 
engineering. 

This thesis involved the setup and evaluation of a 
modified INTEL 432/670 cross development system to measure 
the overall performance of the programming language ADA 
executing on a companion vehicle, the INTEL lAPX -432 



3 



microprocessor. The motivation for this investigation was 
straightforward. Since the Department of Defense has spent 
considerable time and effort In developing the ADA language 
It would be Interesting to observe how the language performs 
on a processor that was designed with Identical goals. It is 
not often that a language and processor are developed In 
parallel. More importantly, the INTEL lAPX-432's unique 
architecture directly supports many of the important ADA 
language features. Such as: 

1, Access protection for packages, 

2, Automatic maintenance of activation record stacks. 

3, Multiprocessor support for multitasking. 

This support mav provide for less expensive, easier to 
maintain software, a common objective of both hardware and 
software designers, 

B. EVALUATION OF COMPUTER ARCHITECTURES 

Evaluation of computer architectures and computer 
languages has traditionally been an Investigative process 
directed toward a specific application. This study involved 
the general purpose applicability of the language and the 
processor. The choice of measurement methods used followed 
an earlier effort performed by the Computer Family 
Architecture committee in 1976 concerning general purpose 
computer application evaluations. In particular, some of the 
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benchmarx programs used by the committee were coded in ADA 
and then executed and timed on the lAPx-432, Although no 
provisions have been made to eliminate the effects of 
compiler efficiency, or inefficiency, the results should 
give an indication of the execution speed available to the 
end user. This method of testing was chosen since the 
processor is designed to be programmed in a high level 
lanouage CADA), No assembler is under development or planned 
for by the manufacturer. Therefore, if the language and 
processor are to be used as designed, then the performance 
needs to be evaluated in a wording environment. That is, 
programmers programming in ADA and complied code executing 
on the processor. 

C. THESIS ORGANIZATION 

This thesis is composed of six chapters and five 
appendices. Chapter II is a brief discussion of the worX 
done by the Computer Family Architecture committee (CFA) and 
it's applicability to this investigation. Chapter III is an 
introduction to some of the unioue architectural aspects of 
the iAPX-432 and how these new features support the language 
ADA. The henchmarX program descriptions and timing results 
are in Chapter IV. Included in that chapter is a description 
of the parameters passed and the calling conventions used. 
An attempt has been made to give an impartial evaluation of 
the CDS 432/670 system in Chapter v. Finally, in Chapter vi 
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the reader will find what basic conclusions have been drawn 



about the lAPX-432 and the CDS 
- this study. The appendices 
necessary to reoeat any of the 
IV. They Include a description 
system modifications performed 
source cede. As a convenient 
by the CFA are provided In Appe 
Included In Appendix E to allow 
familiar with the system. 



432/670 system as a result of 
are filled with the material 
results obtained In Chapter 
of the hardware and operating 
and a listing of all the ADA 
reference the algorithms used 
ndlx D. A users manual Is 
a new user to quickly become 
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II, THE MILITARY CQf^PUTER FAMILY ARCHITECTURE 



The Military Computer Family Architecture (MCF) refers 
to the architecture standard defined in a study done by the 
Computer Family Architecture committee (CFA) between October 
of 1975 and August of 1976, The Initial study concluded that 
the POP-H best met the criteria for a military computer 
family standard. Since that time another CFA related study 
by Dletztll suggested several improvements In the algorithms 
used to evaluate architectures. An overview of the CFA 
project follows, 

A. . CFA/MCF PROJECT MOTIVATION 

The CFA/MCF oroject was a joint' ARMY/NAVY effort to 
develop a method of comparing computer architectures for use 
on a general class of applications. The enormous sums of 
money that the Department of Defense was spending on data 
processing promoted the Investigation into the possibility 
of defining a standard computer architecture, Decreasing the 
life cycle costs of computer systems played a major role in 
the committees selection criteria. 

B. CFA/MCF PROJECT DESCRIPTION 

One of the first Items the CFA examined was the reason 
for skyrocketing data orocesslng costs. The answers they 
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obtained were not too surprising. That is, computer 
selections often are based on local schedules, funding, and 
profit considerations with little regard for the Impact 
these decisions have on long term hardware/software 
logistics costs. Consequently, incompatible military systems 
are contributing to the problems of development and 
maintenance of software. Although a formal movement in 
standardizing a language was underway (ADA), there was no 
method for standardizing an architecture. It was with this 
mandate that the CFA committee pursued the evaluation of 
several available computer architectures, with the goal of 
selecting a standard, 

A standard architecture does not mean specific numbers 
of registers, accumulators etc,, but rather the structure of 
the machine that a programmer needs to >cnow to write his 
programs. For example, if the architecture standard reaulres 
staoc relative addressing, then any machine having that 
Instruction (and the other reauired instructions!) can be 
programmed by a given programmer without his having any 
Knowledge of how the instruction is Implemented, The 
programmer Knows there's a stacK and a stacK relative 
address Instruction; the hardware implementation is 
transparent to him. In this fashion, any two computers 
having the standard architecture can run the same software. 
The advantage realized Is that new hardware with faster, 
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more efficient physical characteristics, can run the same 
software with little or no modification. 



C. CFA SELECTION CRITERIA 

The CFA committee initiated the selection process by 
speclfylnc nine absolute qualitative criteria and several 
quantitative criteria that they felt an architecture must 
satisfy to meet t'^e needs of a military computer system. 

1 , Qualitati ve Criteria 

The nine qualitative criteria were: 



1. Virtual Memory ; The architecture must support a 
virtual address to physical address translation 
mechanism . 

2. Protection : The capability must exist to add new 
exoerimental programs without endangering the 
liable operation of existing Programs. Architec- 
tures with orivlleqed' modes of operation 
generally meet this criteria, 

3. Floating Point Operations : The explicit supoort 
of floating point data types with more than 10 
decimal digits of significance. 

4. Interrupts and Traos : The capability to write a 
trap handler to respond to any trap condition 
with the program resuming operation of the pro- 
gram. Additionally, the architecture needs to be 
capable of resuming execution following any in- 
terrupt . 

5. Subsettablllty ; Some of the components of the 
architecture must be able to be factored out of 
the full architecture, 

6. Multiprocessing : Suoport of communication and 
synchronization of multiple processors, 

7. I/O Controllability : A processor must have the 
ability to exercise absolute control over any l/n 
processor , 
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, Extensibility : Some method needs to exist to add 
new instructions to the architecture consistent 
with existing formats, 

9, Read Only Code ! It must be possible to execute 
programs from read only memory. 

These nine criteria were definitely subjective in nature but 
did provide a good initial screening for any standard 
architecture candidate, Although the study was done before 
the introduction of the INTEL lAPX-432# most of the criteria 
are met or exceeded by the lAPX-432 with the exception of 
the Interrupt capability. The lAPX-432 has no hardware 
Interrupt, however, it is designed to operate with an 
attached processor which does have an interrupt capability, 

2 , Quantitative Crtrerla 

The guantltative criteria judged by the CFA 
committee Included the following items : 

1, Virtual address space, 

2, Physical address space, 

3, Fraction of address space unasslgned, 

4, Size of the central processor state (amount of 
CPU Information stored on interrupts), 

5, Usage base (number of units in operation), 

6, I/O initiation (efficiency of peripheral device 
accessibility) , 

7, Virtualizablllty (support of virtual machines). 

8, Direct instruction addressability. 
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9. Maximum interrupt latency (time from receipt of 
Interrupt to processing), 

D, MEASUREMENT PARAMETERS 

The quantitative criteria were evaluated, in part, by 
the use of twelve benchmark orograms. These programs were 
hand assembled by several different programmers, and then 
statistically analyzed for program use of computer soace and 
time. The measurement parameters used were; 



S! Measure of soace, the number of bytes used to 
represent a test program, 

M; Measure of execution time, the number of bytes 
transferred between primary memory and the processor 
during execution of the test program, 

P: The number of bytes transferred among Internal 
registers of the processor during execution of the 
test program. 



Although the S,m, and R measures are useful In 
evaluating conventional architectures, they are not readily 
applied to the INTEL lAPX-432, In fact, the microprocessor's 
manufacturer has stated that there Is no intention of 
supplying an assembler, nor Is one under development. This 
would make the measurement of S and M difficult and the 
measurement of R virtually impossible. For this reason, the 
evaluation of the INTEL lAPX-432 was primarily based on the 
execution timing of selected benchmark programs. 
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E. BENCHMARK EVALUATION DESCRIPTION 

The orlalnal CFA committee developed twelve benchmark 
proorams to evaluate the selected criteria, A brief 
description of the proqrams follows with a comolete 
algorithmic description in Appendix D, 

1. I/O kernel, four priority level Interrupts. 

2 . I/O kernel, FIFO orocessinq. 

3. I/O device handler. 

4. Larqe fast Fourier transform of a larqe vector. 

5. Character search. 

6. Bit test: set, or reset. 

7. Runqe-Kutta Inteqration. 

0, Linked list insertion, 

9, quicksort, 

10, ASCII to floatinq point conversion, 

11, Boolean matrix transpose, 

12, Virtual memory space exchanqe. 

These proqrams tested many of the items considered to be of 
value by the CFA committee, however, a later study by Oletz 
Cl] determined that the number and tyoes of test proqrams 
should be expanded. The proposed set of benchmark oroqrams 
consisted of sixteen programs organized into four groups as 
follows ; 
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A, Interrupts and traps. 

1, Terminal input driver, 

2, Message buffering and transmission, 

3, Multiple priority Interrupt handler, 

4, Virtual memory exchange. 

B, Miscellaneous, 

5, scale vector display. 

5, Array manloulation-LU decomposition, 

7. Target tracKing, 

B, Digital communications processing, 

C, Address manipulation, 

9, Hash table search, 

10, Linked list insertion, 

11, Presort, 

12, Autocerreiate, 

D, Character and bit manipulation. 

13, Character search. 

14, Boolean matrix transpose, 

15, Record unpacklna, 

16, Vector to scan line conversion, 

A comoiete algorithmic description of these benchmark 
programs can also be found in Appendix D, 

These sixteen algorithms were thought to more rigorously 
test specific features of the computer family architecture 
standard. None of the above benchmark programs are 
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necessarily firm algorithms that must be adhered to. 
However, they do provide some guidance In the type of tasks 
that must be performed by a computer In order for It to 
fulfill the minimum requirements of an architectural 
standard. In the original evaluation the POP-11 was 
selected as the best candidate architecture for the military 
computer family. Since that time several major advances In 
both hardware and software have occurred. The unique 
architecture of the INTEL lAPX-432 provides a different test 
Platform for the execution of the benchmark programs. Those 
programs which were supported by the current INTEL ADA-432 
compiler were coded, executed, and timed. The results are 
summarized In Charter IV of this thesis. 
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III. THE INTEL 1APX«432 MICROPROCESSOR 



A, ARCHITECTURE DESCRIPTION 

Computer architectures in the majority of commercial 
systems available today can be viewed as refined descendants 
of the often termed Von Neumann computer architecture. A 
Von Neumann com outer architecture usually Includes the 
following properties C23: 



1. A single, seguentlally addressed memory which 
contains both program and data. 

2. No explicit distinctions between instructions and 
data. Rather, instructions and data are dis- 
tinguished by the ooeratlons directed towards 
them. 



In 1981, Intel announced a 32-blt VLSI microprocessor 
incorporating several architectural innovations [3] , This 
announcement stated! 



"The Intel lAPX 432 represents a 
combuter architecture: it is 

whose architecture supports tr 
sparent, multiprocessor operati 
commercial system to supoort 
programming methodology; it 1 
programmed entirely in high-le 
supports a virtual address so 
a trillion bytes; and it supports 
the proposed IEEE-standard for fl 
metlc, " 



dramatic advance in 
the first computer 
ue software tran- 
on; it is the first 
an object-oriented 
s designed to be 
vel languages; it 
ace in excess of 
on the chio Itself 
oatlng point arith- 
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The next few pages will be devoted to orovidlng a brief 
overview of the following architectural aspects of the 
iAPX-432: 

1, Object-Orientation, 

2, Transparent Multiprocessing, 

3, Capability-Based Protection. 

4, Operating system Suopcrt, 

1 , Ob jeet»Qrientation 

What does it mean to be an object-based computer? 
Unlike the classical Von Neumann architecture described in 
the introduction, memory is not accessed as a single, 
contiguous block. Rather, the memory is considered as a 
collection or set of smaller units called objects, each of 
which occupies some contiguous amount of memory. Very 
important and fundamental to this conceot is the object's 
recognition. This can occur in software, or as in the 
majority of cases for the 432, in hardware. This recognition 
enables the object to be typed or classified as to the 
operators which are allowed to act upon the particular 
object. Since the 432 architecture can determine the 
classification of an object it can prevent Incidents such as 
instructions (e.g. Instruction objects) being interpreted as 
data, and conversely, data (e.g. data objects) being 
executed as instructions. 
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At the machine level, objects can be thought of as 
being segments, a segment being a set of contiguous memory 
locations which In the 432 case can range from l to 65,536 
bytes In length. However, there can be some differences In 
the 432 case. Specifically, an object can be any one of the 
following: 

1, A single segment, 

2, A collection of segments, 

3, A part of a segment. 

This latitude in object abstraction gives compiler designers 
a powerful base on which to build object oriented compilers 
(ADA) , 

Intel has moved the recognition of specific object 
types Into the 432 hardware, as alluded to above. 
Additionally, certain ooerators on these objects are 
incorporated directly Into hardware, while other operations 
must be done via software. The net effect of this decision 
is twofold: 

1, Increased reliability of all operations, 

2, Increased execution speed of certain functions. 



Figure 1 Illustrates some typical lAPX -432 hardware 
recognized objects: 
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Figure 1, Hardware Recognized Objects 



The incorporation of an object-based programming 
methodology, in the manufacture's own words, .raises the 
level of the hardware/software Interface”, The justification 
for this statement can be found in the following example. 

Early computers had very simple hardware operations. 
These early machines were not capable of supoorting 
floating-point manipulations directly. If you wanted 
floating-point operations you had to implement them in 
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software, with the passage of time and Increased 
technological progress, computer hardware gained 
functionality. What were once software functions found 
themselves migrated Into hardware, a classic example being 
floating point operations. This evolution of software Into 
hardware Is generally regarded as raising the level of the 
hardware/software interface In a computer architecture. The 
432 carries this progression one step further by placing 
system management operations, such as process scheduling, 
memory management, and Interprocess communication into the 
hardware also. Referring back to Figure l, the importance of 
such objects as processor object, process object, etc, 
should now take on greater significance. Naturally, more 
than these basic system objects will be needed to Implement 
the operations listed above. The processor must be able to 
manipulate these objects In an appropriate way so that what 
Is traditionally done in a series of program steos Is now 
accomplished with a single Instruction, The net effect of 
such hardware instructions is to increase processing speeds. 
Recalling the example of floating point operations, 
we find that their incorporation into hardware increased 
their speed of operation. Furthermore, soeed and reliability 
are significantly enhanced when an operation is implemented 
in hardware. However, the capability based architecture adds 
a sloniflcant amount of execution time to each instruction 
and consequently the performance of a processor is reduced. 
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The choice of an object-based computer architecture, 
besides raising the hardware/software Interface, Integrates 
Ideas that have developed over the last decade In software 
engineering. These Include data abstraction, domain based 
protection. Information hiding, and high-level system 
functionality , The lAPX 432 Is an attempt to bring these 
notions coherently together In a single architecture, 

summarizing, an object can be regarded as possessing 
the following prooertles: 

1, A data structure that contains Information In an 
organized manner. 

2, A set of basic operations may manipulate an ob- 
ject, The 432 hardware ensures that these are the 
only operations that can manipulate the data 
structure, 

3, An object can be addressed as a single entity, 

4, An object has a label which specifies the 
object's type (e,g. processor vs, process). 

Lastly, as regards the relationship between segments 
and objects, a segment refers to the physical structure of 
data In memory, l,e, where the structure is located. An 
object refers to the logical structure of data in memory, 
l.e. how the memory Is used, 

2. Transparent Multiprocessing 

One of the most highly promoted features of the 
lAPX-432 is Its software transparent multiprocessing 
capabilities, also called "incremental comoutlng cower". 
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What this means is that the number of physical processors 
(GDP boards) in the 432/670 system can be chanced without 
any correspondlno changes in application software. That is, 
a user's application program never has to be concerned with 
the number of physical processors present. The only visible 
effect of having more than one physical orocessor is the 
Increase In system throughput. This >cind of flexible 
performance is not usually associated with microcomputers. 
As applications become more complex and more dynamic, it 
becomes increasingly difficult to predict how much 
processing power a system will need to meet its performance 
goals. This uncertainty can be a serious source of risk. An 
application may have to commit Itself to a processor some 
time before any code has actually been written. This problem 
is solved by the lAPX-432 through the use of processor 
objects. Processor objects are abstractions of physical 
processors and hence their behavior can be manipulated like 
any other object. 

Transparent multiprocessing is accomplished through 
the use of the processor object. The existence of a 
particular physical orocessor is Immaterial. System 
throughput can be increased by adding physical processors 
(GDP boards) and therefore creating more processor objects. 
More processor objects means that more user processes can 
execute. Similarly, the removal of a physical orocessor 
results in the removal of a processor object and a 
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subsequent reduction in the total performance, 
tolerance can thus be said to be Improved by the fact that 
In a multiple processor environment, if a processor falls, 
it is simply removed from the system. The only effect should 
be some reduction In throughput. In order to describe how 
this "software transparent" multiprocessing Is achieved, 
other 432 objects besides processor objects and process 
objects, will be Introduced, Process objects can be equated 
with user programs In the discussion which follows. 

The term dispatching refers to the assignment of a 
432 processor to some process which Is waiting to execute. 
In the 432 case, this Is the palrlng-up of a processor 
object with a process object. The manner in which this Is 
done Is throuah the aid of another particular type of object 
called a dispatching port object. Since this Is an object. 
It also has certain unloue operators which apply to It, The 
dispatching oort object can be thought of as a queue-like 
data structure which can contain process objects or 
processor objects, but never both. Processors, and hence 
their processor objects, are self dispatching on the 432, 
Therefore, when a processor completes Its current task or 
process It examines the dispatching port object to determine 
If there Is a waiting process, represented py a process 
object, enqueued at the dlsoatchlng port. If there Is a 
process object present, the process object Is "bound" to the 
processor object, that Is, a link is formed between the 
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processor object and process object. The processor then 
dequeues the process object from the dispatching port, and 
then oroceeds to execute the process. Conversely, If there 
are no processes (process objects) enqueued at the 
dispatching port, the processor enqueues its processor 
object at the dispatching port, in effect waiting for the 
next ready process. Processes are not dependent on 
specifically which processor is executing it, or how many 
processors are present in the system. Processes ready for 
execution are slmoly enqueued at the dispatching port. The 
presence of more physical processors simply means that the 
average time a process is queued up at a dispatching port 
should be decreased, 

3, Capability Based Protection 

Sharing data among a computer system's users in a 
carefully controlled way has been a subject for much 
investloation in computer systems. Implementation technlaues 
aimed at providing for this controlled information flow have 
run from introducing privileged and user instructions (e,g, 
IBM 360/370) to hierarchical protection systems as 
classically illustrated In the MULTICS rino structure. 
Intel's approach to this Problem in the 432 architecture has 
been to implement what are termed capabilities. 

Capabilities can be thought of as tickets, the 
possession of which conveys privileges, normally the 
privilege to access a segment. In the 432 case, to think of 
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them as a pointer plus access rights pair would be an even 
closer analogy. Possession of a capability means that access 
- to a segment is allowed under the access rights associated 
with that capability. Access rights are? read, write, both, 
or neither. In order to ensure protection, certain processes 
should not be permitted to possess capabilities which grant 
non-dlscriminate access to certain oortlons of memory. For 
example, user processes should not have access to the memory 
where the operating system Is contained. Therefore, because 
of their function and Inherent potential to be used 
maliciously, capabilities must be unforgeable. In the lAPX- 
432, capabilities are recognised and ooerated on by hardware 
to assure this needed protection. The set of capabilities 
accessible to a process at any one time is called the domain 
of protection. As a process runs, the domain of protection 
will change. The ideal to be realized is that the domain of 
protection should always be exactly matched to the 
requirements of the process; that Is, it should contain 
capabilities for all the segments that the process needs to 
access and nothing more. This satisfies the prlnciole of 
'minimum prlvileoe' in secure systems jargon. 

The original reasons that led to the desire to 
design a computer with a capability based architecture may 
be summarized under ruggedness and security. Ruggedness in 
this sense means the ability of the system to survive the 
consequences of hardware failures or software bugs C4] , 
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Security, on the other hand, can be thought of as ensuring 
that access to memory Is determined exclusively by the 
access rlahts of the particular process In question. 

There are basically two distinct ways of 
Implementing capabilities In hardware. These can be termed 
the tagged and partitioned approach fsi. in the former, all 
words In the system carry a 'tag' bit which Plays no part 
other than to Indicate whether the particular word Is a 
capability or not. In the partitioned approach, words carry 
no tag, so It Is not possible by examining a word In memory 
to determine whether It Is a capability or data word. 
Instead, the type of segment is Important, l,e, there must 
be capability segments which contain capabilities and 
nothing more, and 'data' segments which contain anything but 
capabilities. The lAPX 432 uses the partitioned approach, 

Intel's decision to implement the partitioned 
approach causes us to sllahtly refine the concept of an 
object as discussed earlier. As was previously stated, 
objects In their physical form are equated with segment(s), 
A combination of an object-based architecture with 
capabilities implemented In the partitioned approach means 
that each object Is composed of two distinct parts, a data 
part and a capability part. Indeed, in the 432 architecture 
there are two fundamental segment base types. These base 
types are called data segments and access segments, A data 
segment can contain anything exceot capabilities, whereas an 
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access segment can contain only capabilities. Therefore, an 
object should now be correctly envisioned as being comprised 
of these two segment types. An example of how this Is 
actually Implemented for some of the system objects is 
shown In Figure 2, 
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Figure 2, Object Representation 



summarizing, Intel has Implemented capability based 
support for memory protection In the 432, These capabilities 
can be thought of as an address of, or pointer to, an object 
with an attached tyoe describing the classification of the 
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referenced object (e.g, process object# context object#etc,) 
and an attacned protection mode Ce.g, read only or 
read/write), in the 432, Intel has decided to call 
capabilities access descriptors because of their similarity 
In concept to pointer implementation in ADA which is termed 
ah 'access'. Furthermore, objects In the 432 system are seen 
to be comprised of both data segment(s) and capability 
(access descriptor) segmentCs). The data segment of an 
object could be thought of as containing Information 
Intrinsic to the particular type of object , The caoabillt’y 
segment on the other hand, contains caoabilltles for all the 
other Objects it may need to reference. Additionally, 
capabilities are seen to enforce the principle of minimum 
privilege. Perhaps providing an Important insight into 432 
performance, M.v. wlli<es has said [63; 



"Compared with a conventional computer system, there 
will inevitably be a cost to be met In providing a 
system In which the domains of protection are small 
and freguently changed. This cost will manifest It- 
self in terms of additional hardware, decreased 
run-time speed, and increased memory occupancy. It 
Is at present an ooen question whether, by the adop- 
tion of the capability approach, the cost can be 
reduced to reasonable proportions," 



4. Qp.era.ting System Support 

Like the 432 hardware, Intel has created an object- 
oriented operating system for the lAPX 432 called iMAX, It 
has been designed as a multiprocessor operating system, and 
conseauently It accommodates any number of running 
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processors. As a result, all synchronization within the 
system must be explicit. Furthermore, as the manufacturer 
has pointed out C7] , the 432 and IMAX are products primarily 
intended to be used bv original equipment manufacturers in 
the construction of their products. Related to this is the 
fact that IMAX does not provide a command language or a 
human Interface, rather it is designed to provide executive 
services to user-provided software which makes calls to 



IMAX, 

Many traditional operating system primitives are 
Implemented as hardware functions in the 432, In an effort 
to elaborate on the relationship between the IMAX operating 
system and the IAPX-432 functions, a digression is in order. 
As pointed out earlier, the lAPX 432 architecture provides a 
higher level of functionality in hardware than conventional 
computers. Important system management functions are 
realized through hardware-recognized representations, l,e. 
objects. High level operations on these system objects (see 
Fig, Cll), such as sending a message between processes, are 
provided as single machine Instructions, These features of 
the 432 are referred to as the Silicon Operating system. 
These features are not in themselves an operating system, 
but contribute greatly to the building of one. 

The relationship between IMAX and the hardware might 
best be described as cooperation, iMAX doesn't simply run on 
the hardware, rather the hardware acts autonomously to 



33 




A 



provide Important services# such as processor sel£- 
dlspatchlng as pointed out earlier. A good example of the 
division of labor which occurs between IMAX and the 432 
hardware can be found in storage management. Hardware 
defines system objects used for storage management, provides 
single Instructions that allocate new objects, and sets flag 
bits needed for storage reclamation and virtual storage 
management . IMAX will then provide services which win 
create and reclaim local storage pools and will provide 
processes which compact storage and reclaim unreferenced 
objects . 

Probably the most notable point about IMAX Is that 
the user may view IMAX as a set of ADA package 
specifications, each of which corresponds to a particular 
service provided by the system. Additionally, there Is no 
distinction between IMAX packages and user-written packages, 
IMAX operations and user operations are invoked In the same 
way. There Is no special calling convention, no 'Supervisor 
Call' Instruction, as Is the case In many current commercial 
systems. The effect of this particular implementation is 
twofold: 

1. Users can create subsets of IMAX by omitting 
unused packages, 

2, Users can create supersets of IMAX by adding 
their own packages. 
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I MAX also benefits from tne 432's capability 
protection mechanism described earlier. References for 
system objects can be passed to user processes without fear 
of damage or system compromise because the rights associated 
with these user process capabilities have been modified by 
iMAX appropriately Ce,g. read only). User processes cannot 
corrupt these references passed from iMAX, 

Like the 432 hardware, iMAX is in a continual state 
of change by Intel, Version 1,0, which this thesis worked 
with, is a preliminary version intended to get potential 
users quickly acquainted with it in order to acquire the 
ability to execute ADA programs on the 432, As a result, the 
number of ADA packaoes which the user can tailor to his or 
her application are relatively few, as advertised, the 
following services are orovlded by IMAX, Vi,0: 

1, Configure and initialize a multiple-GDP system, 

2, Read from and write to the debugger console ONLY, 

3, Create and start multiple user processes defined 
at compile time, 

4, Communicate between user processes by exchanging 
messages, 

5, Insoect type, rights, and storage information 
contained in access descriptors and object 
descriptors , 

, Insoect context and process dependent 
In a running program's environment. 
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Information 



Later versions are supposed to support Attached 
Processors which are essentially the means by which the 432 
can communicate with tne outside world. When this support Is 
finally Implemented, the current, severely limited i/o (l.e, 
debugger console only) win be replaced by a variety of 
conventional I/O devices. 

9, AHA LANGUAGE SUPPORT 

AS was previously mentioned, there was a considerable 
amount of parallel development between the ADA language and 
the INTEL lAPX-432, Both the ADA language and the 432 
architecture address many of the problems associated with 
large scale software development orojects. This resulted in 
several architectural constructs which directly support many 
ADA language features, 

1 . abject Typing 

The object orientation of the architecture plays a 
major role in language support. Every object is tyoed by 
the compiler or by the hardware to indicate Its intended 
use. This allows a natural separation of orocedure objects 
from data objects. In addition to 'Intended use' typing, the 
objects are also classified as to their Internal structure. 
This structure can be one of two types, access objects or 
data objects. The access object is an array of access 
descriptors Cto other objects) while data objects are 
structured blocks of data Information, Access objects 
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contain only access descriptors and data objects contain 
only data. This is represented in Figure 3, 




As shown in Figure 3, any set of lAPX-432 objects can be 
represented by a directed graph containing access object 
nodes and data object nodes. This notatlonal convention 
serves as a useful model for representing execution time 
objects and their relationships to corresponding ADA 
programs. It is important to realize that an object can 
exist as the subpart of another object and yet be logically 
different. Such an object that is ohyslcally contained 
Inside a parent object is termed a refinement of the parent 
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object. The refined objects are physically sub-parts of the 
parent object, yet they can inherit the full privileges of 
objects, as if they were physically distinct from the 
parent, in the case of multiple refinements, they can behave 
as if physically distinct from other refinements of the 
parent. This is illustrated in Figure 4, 
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Figure 4, Refinements 



2, Domain Objects - PacKace Objects 

Common data structures and procedures can be grouped 
together using the ADA package construct. The INTEL iAPX-432 
uses a domain object to represent an ADA package. The domain 
object, like a package, is a collection of data objects and 
procedure objects Chence it is of type access). This can 
best be illustrated by the following example of an ADA 
package definition and the corresponding iAPX-432 object 
representation shown in Figure 5, 
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end SUBTRACT; 

end SIMPLE; 


Is 









Figure 5, an& PacXaae and lAPX-432 
Object Correspondence 



Since objects can be refined, It Is possible to refine a 
domain object to create domains of a oacKage with different 
access riohts. This mechanism very nicely supports the 
public and private access rights defined In ADA, A user is 
given access to public information by creating a refined 
object with access descriptors to a refined domain which 
contains only public data, 

3, Procedure Obje cts - Procedures 

An lAPX-432 procedure object consists of executable 
code corresponding to an ADA procedure. The procedure object 
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also contains information required to form the activation 
record or context object which is created on procedure 
invocation. Procedures may be invoked in either Interdomaln 
or Intradomaln contexts. The Interdomaln context means that 
a procedure in one package (domain) is calling a procedure 
in another package (domain). Intradomaln procedure calls are 
simply calls within the same package. 

4, Activation Records 

A block structured languaoe such as ADA can make 
efficient use of activation records. The lAPX-432 supports 
the use of activation records via context access objects and 
context data objects. The context access object represents 
local reference variables and the context data object 
represents local data variables of the activation record. 
The lAPX-432 instructions 'procedure call' and 'procedure 
return' create and destroy context objects, 

5. Tasking 

One of the important multiprocessing features of the 
ADA language is the concept of a task. Tasks are directly 
supported in the lAPX-432 through the use of dispatching and 
communication port objects. The communication port object is 
a message queue that acts as a buffer between Processes that 
may be executing concurrently. It's function is to allow 
inter-process communication, A dispatching port is a special 
form of a message aueue in which a process object may spend 
time waiting for the arrival of an available processor, or 
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where a processor object awaits the arrival of a process. 
These operations are performed In hardware which allows for 
very efficient coding of the ADA tasking model. 

It may be surmised from the previous discussion that the 
language ADA and the INTEL lAPX-432 have several common 
foundations. This was undoubtedly Intentional, The 
microprocessor Is designed to be orogrammed using high level 
languages such as ADA as the development language, No 
assembler Is planned or under development by the 
manufacturer . 
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IV. BENCHMARK PROGRAM TIMING RESULTS 



A, BENCHMARK PROGRAMS 

The benchmark programs were obtained, for the most part, 
from the CFA algorithms referenced in Chanter II, Section E 
"Benchmark Evaluation Description", Some programs from a 
non-CFA related study were also used so that an objective 
timing comparison could be made with other processors, 

1 , Methods Used 

The programs were coded in ADA, compiled using the 
INTEL ADA-432 compiler on a VAX - 11/780 host computer, 
linked on the VAX - 11/780 using the INTEL 432 linker, and 
downloaded to a floppy disk via the INTEL asynchronous 
communications link. Execution of the downloaded object code 
was performed using the INTEL Debugger and Execution 
software package operating on a INTEL MDS System 800, The 
INTEL MDS system is regulred to load the executable code 
into the INTEL 432/670 system for execution on the lAPX-432 
microprocessor. The system setup is shown Figure 6, 
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Figure 6, CDS System Overview 
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In order to actively simulate large scale software 
development (and to exercise some unique ADA features) all 
the coded CFA programs were developed in such a way that the 
program specifications were separate from the program body. 
The effect of this decision was twofold: 

1, Programs could be written and debugged indepen- 
dently by both authors, 

2, The concept and value of using a seoarate program 
specification construct could be demonstrated, 

A careful inspection of each benchmark program will reveal 
that it consists of three primary parts. These parts are; 

1, Pacxage specification. 

2, Package body, 

3, Main or driver procedure. 

The driver routine is needed to initiate a user process in 
the 432/670 system. The oroorams were designed so that the 
user could control the number of times the benchmark was 
Invoked. This allowed for an effective averaging method. 
For example, the benchmark could be executed 100,000 times, 
accurately timed with a stopwatch, and then the total 
elapsed time could be divided by 100,000 to obtain the 
average execution time for the procedure. Each program 
writes a start and a stop message. Including an audible 
'bell' to indicate when to commence and end timing. In 
order to effectively Isolate the procedure Invocation timing 
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overhead from the benchmark timing, there were usually two 
different driver routines with each benchmark program. Each 
program, when executed, would request the number of times to 
perform the algorithm In question. This request could come 
from the driver routine or from the benchmark procedure. If 
it came from the former then the time measured included the 
time required to invoke the procedure, A timing request from 
the benchmark procedure included only the timing reouired to 
perform the algorithm. The difference in the two times was 
then a measure of the procedure invocation overhead. Note 
that this method would not work with a recursive procedure. 
Further discussion of these methods and the mechanics 
involved can be found in Chanter V, "CDS 432/670 User 
Evaluation , " , 

2 . Applicable Algorithms 

The ADA-432 compiler (Version 1,0) does not support 
the full ADA lanouage. The manufacturer has added some 
extensions to the compiler but it presently lacks manv 
Important ADA features. Some of the significant compiler 
limitations are as follows; 

1, Fixed point and floating point types are not im- 
plemented , 

2, Tasking, as defined in the Reference Manual for 
the ADA Programming Language, is not imolemented, 

3, Array operations, such as concatenation, assign- 
ment, and boolean operations are not implemented. 
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4. Dynamic arrays and dynamic strings are not Imple- 
manted, 

5. Run time checks are not operational, 

6, Exceptions are not Implemented, 

7, Record representations for records containing 
fields of tyoe access are not implemented. 



Although the above compiler limitations are rather severe it 
was still possible to code several of the CFA algorithms in 
ADA-432 and most of those coded could be executed on the 
iAPX-432. The lack of a hardware interrupt prevented many of 
the CFA benchmarks from being coded. Future releases of the 
432/670 system are supposed to provide the facility of an 
interrupt throuah the use of an attached processor. This 
feature was not available in this release of the 432, A 
short description of each of the executable programs 
follows. The complete source code can be found in Appendix 
C, 

a. Character Search 

This program searched a given string for the 
occurrence of an argument string and returned the location 
of the argument string, if it was located. The program was 
coded from the algorithm in the original CFA study. The 
algorithm is listed in Appendix D, The strings were read 
into a variable of tyoe STRING80, which is an ADA-432 
predefined type required for text I/O, The strings were 
then decomposed into individual characters and assigned to a 
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1 by 256 character array. This method. was necessary because 
of the primitive state of the current ADA-432 text I/O 
package. The program was made interactive to allow for many 
searches to be performed in any given debugglno/executlon 
session. The data structures, calling conventions, and a 
sample expected result are shown in Figure 7, 



Search String: 

I I 

I I I I I I I I I I I I I i I I I I I I I I I 

iMIoInldlalyl,! IJIulnlel I7ltlhl,l Iim7l6! 

I I I I I I I I I I I I I I I I I I I I I I I 

I - I 

123456789 22 

Argument string: 

l-l-l-l 
Idlalyi 
Ul-I.l 
1 2 3 

Search length := 22 
Argument length := 3 

SEARCHCSearch«length, Arg« length ,Search«str , Arg„len , loc) 
expected result : loc = 3 



Figure 7. Character Search 
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Two versions o£ the program were used 



One 



version included the time required to Invoice a procedure 
while the other version did not Include procedure invocation 
overhead. As will be shown in the timing results section of 
this chapter, procedure Invocation Is excensive, 
b. Quicksort 

This program performed a quicksort on a given 
array of records. The program was coded using the CFA 
quicksort algorithm in Appendix D, The records sorted 
consisted of an Integer key field (to be sorted on) and a 
character field associated with each key, A pictorial 
representation of the data structure and the sorting process 
and calling convention is shown in Figure 9, 
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Figure 8, Quicksort 
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The program was written to act Interactively with 
to allow for several different runs per debugging 
Two versions of Quicksort were used, one was an 
sort, the other a recursive sort. The timing res 
that the procedure Invocation overhead of the recur 
was significant, 

c, Hashtable 

This prooram located the position a k 
occupy in a hash table. An example of the data 
used and the calling conventions are shown In Figur 
algorithm for this program was obtained from the s 
study by DletzCll and can be found In Appendix D, 
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Figure 9, Hashtable Data structure 
and Calling Convention 



Since this program used a function, there was only one 
version written. The procedure invocation overhead is 
included in the timing results. 
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d. Digital Communications Processing 

This program sent a message to a given output 
buffer. The algorithm was taKen from the second CFA study by 
Dietz C13 and is located in Appendix D. The data structures 
used for the program and a tyolcal calling convention are 
shown in Figure 10, 
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Figure 10, Digital Communications 
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The program interactively queried for the message 
destination, message connection and the message text. This 
allowed for several sample runs to be performed during a 
debugging session. 

e. Memory Usage 

A close Inspection of the ADA source code in 
Appendix C shows that many of the data structures are auite 
small. This is intentional, and necessary. Early In the 
course of this investigation it was discovered that programs 
would compile correctly but execute in an unpredictable 
manner. The problem was found to be in the amount of heap 
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Memory was written to demonstrate how fast memory was used 
up. The program was fairly simple in that all it did was to 
create an array of 50 characters and a pointer to the array. 
This program was also written in two versions, one that 
created the arrays recursively, the other iteratively. The 
expense of context creation in a recursive procedure was 
shown to be very great. Only nine recursive calls could be 
made before the program used all of the available memory and 
the system crashed. The Iterative version did much better 
and igg separate data structures were created before all 
available memory was exhausted. Of particular Interest to 
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the user is that there Is no indication as to what is wrong 
when the memory is used up. The display is "blanlc” and all 
efforts to use the debug facility resulted in a system 
response of "no current orocess". In summary/ the user must 
laboriously Inspect the program object code (the MAP file) 
and arbitrarily set breakpoints in the code to determine 
what the cause of the fatal error is. This problem is 
elaborated in Chapter V of this thesis, 

3, CFA Coded but not Executed Programs 

Two programs from the first CFA study were coded in 
ADA and executed on an ADA-ED compiler to check for correct 
program execution. These programs were: 

1, Linked List Insertion, 

2, Runge-Kutta Integration, 

Unfortunately the present ADA-432 compiler does not support 
the floating point data type necessary for the integration 
program; nor does the ADA-432 compiler support records with 
access types, which is necessary for the linked list 
insertion program. The ADA source code for these programs is 
located In Appendix C for easy reference to allow for 
possible conversion when a more comolete compiler is 
released , 

4, Non-CFA Related Programs 

Since the CFA study never actually timed the 
benchmark programs in terms of execution speed, it was 
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decided that a physical comparison of the lAPX-432 with 
other processors would be useful. A previous evaluation of 
the lAPX-432 by Hansen C3] in June 1982 provided three 
convenient ADA programs to use. These programs were obtained 
from the Computer Science Department at U.C, Bericeley, 
modified slightly to conform with the current ADA-432 
compiler requirements, and then executed and timed on the 
432/670 system. The three proorams used were; 

1, Search: Search a 120 character string for a 15 
character sub-string, 

2, Sieve; Compute prime numbers, 

3, Acker: Calculate Ackerman's function with argu- 
ments 3 and 6, This Is a recursive computation 
reouirlng more than 170,000 procedure calls. 

The complete ADA source code for the programs can be found 
in Appendix C, The timing results are summarized In Chapter 
IV, 



B, TIMING PROCEDURE AND RESULTS 

All the CFA programs were written so that the user could 
write the arguments from the keyboard and select the number 
of times the program was to execute. Dividing the total 
elapsed time by the number of times the orooram executed 
gave an average value of execution time for the particular 
benchmark. Procedure invocation overhead was subtracted from 
the non-recurslve procedures and both timing values are 
shown in the following discussion. In addition, the 
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parameters used and the number of executions are also 
listed, 

1. CFA Benchmark Program Results. 

The following sections describe the parameters used 
for each benchmark executed# the number of executions 
performed# the total elapsed time (in seconds)# and the 
calculated execution time for a single run. Note that the 
program name corresoonds to the ADA-432 source code for the 
respective program in Appendix C, 
a. Character Search 

The parameters used in this benchmark timing 

were: 

SEARCH STRING : Monday# June 7th# 1976 
ARGUMENT STRING J day 
SEARCH LENGTH ! 22 
ARGUMENT LENGTH : 3 



Program 

name 


Number of 
executions 


Elapsed time 
seconds 


Time 

msec 


CHARSl 


100#000 


315.6 


3.2 


CHARS2 


100,000 


142.3 


1.4 


Floure 


11, Character 


Search Results 
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The program CHARSl Included the time required for 100,000 
procedure Invocations whereas CHARS2 did not. For this 
benchmarlc, Figure 11 shows that the procedure overhead was 
more than twice the time to perform the algorithm! 
b, Quiclcsort 

Two forms of the quicksort algorithm were used, 
one recursive , the other iterative, A twenty element array 
was sorted. The worst case array was chosen, that is, all 
the elements were inversely ordered. Figure 12 represents 
the parameters passed; unsorted arrayl was passed to the 
procedure and the sorted array2 resulted. 



arrayl ; 

20 19 19 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 



array2 ; 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 



Program 


Number of 


Elapsed time 


Time 


name 


executions 


seconds 


msec 


OUTCKl 

(recursive) 


1000 


55,8 


.56 


QUTCK2 

(non recursive) 


1000 


40.5 


.41 



Figure 12, Quicksort Results 
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As expected, the recursive procedure took considerably 
longer to execute. This is not too surprising since the 
overhead of procedure invocation Is included, 
c, Hashtable 

The hashtable algorithm was implemented as a 
function. The timing results therefore include the function 
call overhead. This function used the sample hash table from 
the CFA study and a key value of 41 was used as the araument 
of the function. The hashtable's initial values, calling 
convention, and timing results are shown in Figure 13, 



key 


1 0 


193 


11 1035 


1035 


183 


86 


0 


183 


183 1 


index 


1 * " " ■ 

1 0 


1 


2 '3 


4 


5 


6 


7 


8 


9 I 



position ;= HASHESC41) 



Program 


Number of 


Elapsed time 


Time 


name 


executions 


seconds 


msec 


HASHl 


100,000 


252 


2.5 



Figure 13. Hashtable Results 



d. Digital Communication Processing 

This procedure sent a thirty character message 
to the output buffer. Figure 14 represents the data values 
passed to the procedure for processing. 
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msg.ptr I I 



message 



10 


1 Ih 1 This is a thirty char 


acter msg 


estinatlon 


connection 


message data 




Program 


Number of 


Elapsed time 


Time 


name 

• 


executions 


seconds 


msec 


DCOMl 


100,000 


286.9 


2.9 


DCOM2 


100,000 

0 


201.6 


2.0 



Figure 14, Digital Communication Results 



In this case the procedure overhead was nearly one third 
that of oerformina the algorithm, 

2, Mon CFA Program Results 

An earlier study of the 432 was performed by 
HansenC3] at U,C. Berxeley, Several benchmark orograms were 
coded and executed on various machines and in several 
different languages, A summary of those results is shown in 
Figure 15, 
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machine 


language 


program 

name 




• 






Search | 


Sieve 


1 


Acker 


432 


ADA 


14.2 1 


3200 


1 


260,000 


4 MHZ 








I 




8086 


PASCAL 


7.3 1 


764 


1 


11100 


5 MHZ 








1 




68000 


PASCAL 


1.3 i 


196 


1 


2750 


16 MHZ 








1 




VAX 


PASCAL 


1.4 \ 


259 


1 


9800 


11/780 


(VMS) 






1 








All times are 


In 


ms*ec 



These results are from a study by HANSENC3] 
which were performed on a 432 version 2, The 
processors manufacturers were ; 8086 - INTEL, 
68000 - motorola, VAX 11/780 - DEC, 



Eioure 15, Previous '^'on CFa Timing Results 



An attempt was made to duplicate the 
the earlier study by executing the benchmar*<c 
CDS 432/670 system. The programs that were 
U,C, Berkeley would not compile under Ver 
compiler supplied with the 432/670 system, 
were passed in using these tests, they were 
code. An examination of the ADA source code 
will also reveal that no effort was made to s 
body from orogram specification. The res 
timing are shown In Figure 16, 



results from 
programs on the 
received from 
Sion 1,0 of the 
No parameters 
included in the 
in Appendix C 
eparate program 
ults from our 
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machine I language 



program 

name 



SEARCH 1 SIEVE I ACKER 



432 
8 MHZ 



ADA 
V 1,0 



21.7 



58.4 I 2000 



Figure 16, Mon CFA Timing Results 
ADA Version 1,0 



Extreme caution must be exercised when comparing these 
values to the previous study. Specifically In the case of 
the SIEVE and ACKER orograms. The limited stack heap 
available prevented implementlna the code exactly as done by 
U,C, Berkeley, The results of the SEARCH benchmark are very 
interesting. The three proarams received from U,C, Berkeley 
required some modification before they would compile 
successfully on the Intel ADA-432 compiler. More 
importantly, our results generally include the time required 
for procedure invocation. In some instances, notably our 
algorithm Implementing the character search, we also have 
results which do not include procedure Invocation overhead. 
Lastly, whereas we used the concent of packages in arriving 
at the coding of our benchmarks, the U,C. Berkeley programs 
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did not. These differences are easily seen by referring to 
Appendix C, 

It is not clear whether the results by HansenC3] 
Include procedure invocation overhead. However, since the 
432 used in this thesis had a 5 MHZ clock rate (with an 8 
MHZ system clock) as opposed to a 4 MHZ clock rkte in the 
Hansen study, one would suspect that running the same 
program with the same data would give at the least, 
comparable results. To our surprise, this was not the case. 
Initially, we timed the SEARCH algorithm sent from Berkeley 
"as is". This was timed at 23 milliseconds, quite a 
difference from 14,2 in the previously cited study, we then 
modified the Berkeley algorithm so as not to include string 
initialization each time. Since our first timing was so 
different from the Berkeley study we thought that string 
initialization should not be included in the results. The 
second test was made by just timing the Berkeley search 
function alone. This Included procedure invocation overhead. 
The result is listed In Figure 16, 

C. SUMMARY OF RESULTS 

The data In the previous figures pertinent to the CFA 
studies, is summarized in Figure 17, It is believed by the 
authors that the following times represent realistic 
execution speeds available to a user performing in the 
working environment of the present 432/670 system. 



59 



Program 

description 


execution speed 
msec 




Character Search 


i.4 


Quicksort (recursive) 


0,56 


Quicksort (non-recursive) 


0,41 


Hashtable lookup 


2,5 


Digital Communication 


2,0 



Figure 17, 


Execution 


Speed Result Summary 


The data reported 


above 


does 


not include the 


procedure 


invocation overhead. 


with 


the 


exception of the 


recursive 



QulcKsort and the function Hashtable Lookup, It needs to be 
emphasized that the numbers are only 'rules of thumb' that 
should be used in descrlblnc the execution speed of the 
iAPX-43?, Compiler differences, and just as importantly the 
argument used in the algorithm, can significantly affect the 
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execution speed. For example. If the character string 
searched for In the Character Search Is near the beginning 
of the search string vs, near the end of the search string, 
the results can vary by as much as a factor of ten, (The 
length of the string searched also plays a significant role 
in determining execution time). The exact arguments passed 
and the calling conventions used have been described in 
detail (Chapter IV, A) for future reference and comparison. 
The values in Figure 17 represent an approximation to 
the time required to perform a given algorithm. In order to 
cross check and verify the timing results, an effort was 
made to time a single lAPX-432 instruction. This was 
accomplished by writing two test programs, TlOO and TlOl, 
which differed by a sinale line of source code. That is, 
TlOO executed "A != B - C" one hundred times and TlOl 
executed ’♦A != B • C” one hundred and one times. An 
examination of the MAP file (the compiler output) revealed 
that the code differed by one statement. That statement was 
"sub„l", an lAPX-432 mnemonic for subtract integer. The time 
difference between the two programs could then give a figure 
for the execution speed of the single sub.l instruction. The 
measured speed could be directly compared with a previous 
study C8] which timed individual instruction speeds on a 
4MHZ lAPX-432/100 Verslonl. The results are summarized in 
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Figure 19 



Program 


Number of 


timeCsec) 


difference 


name 


sub«i executions 






TIOO 


! 40,000,000 


i 777.8 


1 








6,90 


TlOi 


1 40,400,000 


t 784.7 


1 


execution time 






sub«i 


= 6.90 / 400, 


000 = 1,73 


X 10-5 sec 



sub.l sub.l 

Version 1 5MHZ Version 2 5MHZ 

estimated cycles measured cycles 
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Estimated cycles are from an earlier study C83 
on a 432/100 system and represent a projection 
based on measured results. Version 2 measured 
cycles are the result of the product of execution 
time and the clock rate. 



Fioure 19. Individual Instruction Timing 



As can be seen in Figure 18, the measured speed of the 
sub«l Instruction in this study is in good agreement with 
the previous results. The differences can possibly be 
accounted for in the fact that two different versions of the 
microprocessor are being compared. 

An attempt was also made to eliminate the effects of 
"dead time", or "time out" in the execution of a program. 
This time out is the oerlod during which a process is 
suspended while the dispatching port is checked for another 
process to be assigned to a processor. Normally a process is 
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given a default value of 0,2 seconds of dedicated processor 
time between time outs. Since only one program was executing 
at a time, it was not believed that the program timing 
results would be significantly affected by the dispatching 
port check overhead. To verify this, a modification was made 
to the INTEL supplied ADA package PSERP.MBS, The 
modification increased the time slice from 0,2 seconds to 7 
seconds, Similar programs that differed only in the time 
slice period (0,2 seconds vs 2 seconds) executed within 0.5 
seconds of each other over a total execution time of 200 
seconds. This confirmed that the time slice period between 
dispatching port checks was not significantly interfering 
with the benchmark results. 
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V. CDS 432/670 USER EVALUATION 



In the process of working on this thesis both authors 
felt that a section devoted to constructive criticism of the 
INTEL Cross Development System would be appropriate, 9y 
Cross Development System we mean the INTEL ADA compiler, 
linker, downloading and execution software and corresponding 
documentation. Additionally we conclude with some of our 
thoughts on ADA, We understand that many of the problems 
addressed here are not permanent, and very likely many of 
the items we have found to be mysterious or Irksome may have 
already been corrected in a later release. 

The INTEL 432/670 system can be conveniently divided 
Into four major components: 

1, Comolier, 

2, Linker, 

3, Downloading and Asynchronous Communication, 

4, Debugging and Execution, 

The following discussion will treat each component in turn, 
stating what positive and negative attributes we found, 

A, COMPILER 

The ADA-432 compiler does not support full ADA. The 
language limitations are listed in Chapter IV. Of these, the 
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lack of floating point number support was felt to be 
extremely burdensome to this thesis, A great many of the CFA 
measures are focused on floating point manipulation, as are 
many real world applications. At the machine level, the 
lAPX-432 has outstanding floating point suooort, such as 
multiply, divide, and square root machine instructions. The 
lack of compiler supoort for floating point operations 
prevented us from testing proorams in an area where the 
iAPX-432 should provide outstanding performance. 

The present text I/O package provided in the ADA-432 
compiler can best be described as primitive. The user is 
given a choice as to how messages can be input and output to 
and from the screen, that is, the message can be l, 10, 20, 
30 or 80 characters long, and of no other length. Counting 
the numoer of characters in one's input and output text 
significantly detracts from the art of proarammlng. 

Compilation of a user's ADA source code is performed on 
the host VAX 11/780 and it proceeds at a respectable rate, 
the turn around time was always less than a minute. The 
number of compilation errors is displayed at the end of 
compilation, however the reason for the errors is not. To 
evaluate the compilation errors, INTEL has supplied a very 
useful report facility which is an image of the original ADA 
source code with errors identified by a diagnostic message 
and code number. Unfortunately, many of the error code 
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numbers in the INTEL reference manual Just repeat the same 
diagnostic error message, with no further elaboration. 

There was one very frustratlno aspect of the compiler 
output to the screen. That Is, after compilation is 
complete, there is no message as to what unit was Just 
compiled. Since the compiler output often scrolls the 
screen, this leaves it up to the user to remember what unit 
has Just been compiled, ADA programs consist of many units, 
and in more than one instance we found ourselves recompiling 
a unit that had Just been compiled, A very simple solution 
to this would be to output the compiled unit's name as the 
last line of output along with the error messages. 

As with most new compilers, there are some errors. The 
more significant of these are the type that allowed 
compilation of code representing features that are not yet 
implemented. For example, array assignments are not yet 
operational, yet a source code program containing them 
compiles with no error messages. Execution, as expected, 
does not occur. Most of the ADA restrictions are well 
documented in the error report file, however, it only taices 
one or two which are not identified to cause significant 
problems in debuoging a program. At least one type of error 
crashes the comoiler. That is, a program which needs a 
large data structure may never compile and furthermore the 
user will never be informed as to the reason for the 
failure. This problem occurred with the following program 
unit ; 
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type Item is 
record 

key ! Integer; 
data ! character; 
end record; 

type array.one Is arrayCl , ,2000) of item; 

m m 

begin 



When array.one had 2000 elements the program unit crashed 
the compiler. Lowering the number of elements to 200 
allowed satisfactory compilation, 

9, LINKER 

The linking process of a users program Is tedious, A 
separate link program needs to be written for each program 
that Is to be linked. The time to link a program Is 
considerable, usually In the range of two to three minutes. 
Many default parameters occur In the linking process which 
can be changed by directives in the users link program, no 
problems were experienced with the default values, but 
depending on a default value for proper program execution 
can easily lead to difficult debugging errors In future 
prooram maintenance. In our opinion all the directives 
should be required to be explicitly stated. 

The linker has at least one ambiguous characteristic. 
After a successful linkage, a message Is written to the 
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screen which states ’’LINKAGE SUCCESSFUL". This message may 
also be accompanied by one or more warning messages. In 
every case that we experienced, i£ a warning message 
occurred during linking then the program would not execute. 
The message "LINKAGE SUCCESSFUL" can be very misleading, 

C, DOWNLOADING 

The process of downloading programs from the host VAX 
11/780 system is probably the biggest drawback to the 
432/670 system. Since the iMAX operating system Is part of 
the downloaded object files (EOD), the files reoulrlng 
transfer are quite large, A typical small ADA program (less 
than 100 lines of source code) takes nearly twenty minutes 
to download at 2400 baud. This makes program changes very 
time consuming. Even if a 9600 baud line were used, the 
entire process of correcting source code, re-compiling 
affected modules, and then downloading them, requires a 
significant amount of time. There is a program called 
update for merging a recompiled module of a program with 
the existing EOD file. The smaller re-compiled module is 
much faster to download, about seven minutes, but the UPDATE 
program takes about 3 to 4 minutes to execute. The time 
saved was not considered significant to warrant use of the 
UPDATE feature. Especially since a new link program would 
have to be written each time It was desired to recompile a 
portion of a orogram. 
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D, DEBUGGING AND EXECUTION 

Our impression of the debug facility was favorable, it 
allowed for access to the program structure at an assembly 
language level. This did not allow any type of assembly-lixe 
programming but did provide a means to locate errors in our 
source code by mapping the error location to a source code 
statement number. A very useful utility Is the LOG program. 
This allows everything that was Input or output at the 
terminal to be logged for future reference. The debug 
facility could be made much more user friendly by 
implementing the ADA exception features. At present# the 
lack of exceptions means that run time errors may not be 
reported, and indeed may cause the system to crash with no 
indication to the user as to the cause. An example of this 
occurred when one of our orograms attempted to index an 
array outside the declared array bounds. No error messages 
were reported, and the system crashed. 

The execution of a program was difficult to Initiate, 
The following seguence of commands represents the minimum 
time required to execute a program after the power is turned 
on and the ISIS-II operating system is booted. The times are 
approximate and they depend on the size of the program that 
is going to be executed. 
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command 



time required 



RUN WORK :F0: 

RUN DE3432 
INCLUDE DEB432.TEM 
INIT 

DEBUG "userprogram” 
START 



5 min, 
I min, 
1 min, 
1 min, 
1 min. 



Once the system debugger Is loaded Conce per session) things 
proceed a little faster. Only the last three commands of 
INIT, DEBUG, and START are required per program, 

E, ADA IMPRESSIONS 

One of the many interesting facets of working on this 
thesis was the exposure to the new OoO language ADA. 
Inasmuch as our use of ADA was limited to the benchmarks in 
this thesis, plus the fact that we dealt with a compiler 
which did not fully implement the language , our impressions 
are limited. However, the features of ADA we did exercise 
left us with some favorable imoressions. 

The feature we used and liked most was the ability to 
separate the specifications of a program from the 
corresponding body of the program. The package feature of 
ADA was used to do this, A specification package is simply 
the formalizing in ADA of what the interface of the program 
is to be, l.e., the 'what' of the program. The body package 
on the other hand is the formalizing in ADA of the manner in 
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which one plans to Implement the program, l.e,, the 'how' of 
the program. The contribution of this separation is 
twofold: 



1, Given a specification package, a programmer is 
free to implement the program in the manner he or 
she sees fit, so long as it satisfies the specif- 
ication, or interface, 

2, Users of a particular program or programs need 
only be given the specification package in order 
to discern what the particular code can do for 
them. The 'how' of the code, or the body package, 
need not concern them. 



Using this technique in very large software projects 
should have a significant effect on software development and 
maintenance, in our small scale projects the separation of 
specification and body allowed for easy parallel development 
of the benchmark programs. The acceptance of ADA by DoD 
computer personnel could be seen to lead to: 



1, The growth of software libraries with specifica- 
tion packages as the user interface to the li- 
brary, 

2, Greater productivity among programmers. For in- 
stance, suppose a decision is reached on what a 
Particular piece of software is to do. This 
"what" is formalized in ADA, and given to the 
programmer(s) , The programmer is now free to 
bring all of his or her abilities to bear on suc- 
cessfully Implementing the body, or the "how" of 
the Piece of software. 



Both of these abilities are generally regarded to be very 
worthwhile, something which up to now has been pursued with 
no great degree of success. Supporting and thereby 
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facilitating this feature of packages is the separate 
compilation ability of ADA, while still enforcing strong 
type-checking of Interfaces, That is, making sure that 
parameters in the body package are of the exact same kind as 
those delineated in the specification, which may have been 
compiled some time before actual coding was ever begun on 
the body. 
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VI. CONCLUSIONS 



In Its present state the INTEL Cross Development System 
(CDSD Is very much a development tool. Areas which we feel 
could be Changed to improve the user friendliness of the 
system have oeen presented in the previous chanter. 

As an execution vehicle for the ADA language, the 
processor seems especially well suited. However, the 
incompleteness of the compiler did not permit us to 
rigorously exercise the 432 as much as we wanted to. Though 

the 432 and ADA seem esoeclally well matched, it is not 

0 

reflected in program execution speed. An object-oriented 
architecture, which also incorporates system management 
facilities in hardware', undoubtedly must have some 
drawbacks. In this version of the 432, this was 
unfortunately reflected in execution speed. As an aside, 
when the compiler comes to support floating point 
operations, benchmarks which exercise floating point 
manipulations should provide some interesting results. As 
elaborated previously, hardware support for floating point 
operations in the 432 are outstanding. 

The lack of a hardware Interrupt is a handicap that 
should be capable of being overcome through the use of the 
attached processor. This feature was not operational on the 
432/670 system and therefore could not be tested. 
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The tlmlnq performance of the system, at first glance, 
does not present a very favorable impression. The benchmark 
programs that were compared with the previous study by 
HansenCSl confirmed that- the 432 is slow in it's execution 
speed. Execution speed Is but one of many measures of any 
computer architecture. It is, however, a measure which 
readily lends itself to numerical analysis as opposed to 
qualitative features which do not. This subjective 
qualitative category can include such items as the amount of 
fault tolerance and protection available. 

The multiprocessor capabilities of the 432 provide a 
case study in some of the Issues which must be addressed by 
any system using multlprocesslno. Moreover, the system in 
general oermits one to analyze the more basic concepts of an 
operating system. Processes, Inter-orocess communication, 
ready, running, and blocked states are all generic terms to 
the architecture. Any study of the processor's architecture 
cannot help but to provide an excellent insight into these 
concepts , 

Finally, the architecture has been designed to be 
programmed in a high level language only. As the compiler 
inefficiencies are removed and the cost of procedure 
invocation is lowered the 432 should show a marked 
Improvement in it's overall performance. 
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APPENDIX A 



HARDWARE DESCRIPTION 



This thesis used a ntodifled INTEL MDS SYSTEM 800 
Interfaced with the iAPX-432 execution vehicle. This setup 
reauired a special circuit board to allow communication 
between the MDS 800 system and the 432/670, The chassis 
name, slot number, and board number of the system components 
used In this evaluation follow. 



Card cage number to circuit board identification 
MDS-800 Doard description; 



1 , 

2 . 

3, 

4, 

5, RPB-86 

6 , 

7, 

8 , 

9, 

10 , 

11 . 

12 , 

13, 

14, 

15, 

16, 

17, 432 IP INTEL 432/670 172080-006-rev H 
S/N-XP-000198 

18, 

432/670 board description: 



1 . 

2 . 

3, 

4, 
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5, MEMORY INTEL 112340-004 REV C 112354-001 REV c 
S/N 000279 

6, MEMORY INTEL 112340-004 REV C 112354-001 REV C 
S/N 000262 

7, MEMORY CONTROLLER INTEL 172075-005 REV E 
S/N -xp-000033 

9. GDP INTEL 432/601 005 REV F S/N-xp-000 1 87 

9, GDP INTEL 432/601 MF-006 REV H S/N-xp-000104 

10, GDP INTEL 11/16/82 432/601 MF-005 REV F 

S/N-xp-000095 MD-17-0003 

11 , 

12,IP»LINK INTEL 432/603 172028-004 REV E 
S/N-xp-000-227 



76 



APPENDIX B 



OPERATING SYSTEM MODIFICATIONS 



The lMAX-432 operating system supplied with the 432/670 
was not compatible with the hardware configuration. 
Specifically, interface processors are not yet supported, 
even though the lMAX-432 operating system Is configured for 
them. This necessitated a change to the ADA oackage body 
that describes the system processor configuration. The name 
of this package is PSORS.MBS, The code referring to the 
number of processors and Interface processors in the package 
body PSORS.MBS must be changed to reflect the current 
physical state of the 432/670 system. For a three GDP board 
configuration with no IPL boards, the PSORS.MBS would 
include the following description: 



•- Define GDP boards present 

package psorl is new GDP-Def (psor,num => 1); 

package psor2 is new GDP-Def ( psor^num s> 2); 

package psor3 is new GDP-Def (psor^num => 3): 

processorl; processor retypes psorl, psor; 
processor2: processor retypes psor2,psor; 
processor3: processor retypes psor3,psor; 

-- Define empty slots 

processors: constant processor := null; 
processor4: constant processor := null; 
processors: constant processor := null; 



A complete discussion as to now these changes can be 
Incorporated In the PSORS.MBS package can be found in 
Reference 7. 
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APPENDIX C 



ADA SOURCE CODE 

All of the benchmark programs that were coded In ADA 
follow. Most proorams are composed of three parts. That is, 
a package specification, oackage body, and a driver or main 



routine. The respective carts are labeled accordingly. The 



programs obtained from U.C, Berkeley are composed of just a 
single main routine. For easy cross reference the program 
name and the corresponding benchmark program are listed 
below, 

program namel program description 


CHARSl 


• 

• 


Character search with procedure 
overhead , 


CHARS2 


• 

• 


Character search without procedure 
overhead. 


QUICKl 


• 

f 


Quicksort iterative 


0UICK2 


• 

• 


Quicksort recursive 


HASHl 


• 

• 


Hash function 


DCOMl 


• 

• 


Digital Communication with procedure 
overhead , 


DC0M2 


• 

• 


Digital Communications without crocedure 
overhead. 


MEMl 


• 

• 


Recursive memory test 


MEM 2 


• 

• 


Iterative memory test 


SEARCH 


• 

• 


U.C, Berkeley character search 


SIEVE 


• 

• 


U.C, Berkeley prime numoer generator 


ACKER 


• 

• 


U.C, Berkeley Ackerman's function 
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In addition to the programs above 






two other programs were 



coded in ADA but were not executed due to compiler 
limitations. The Runge-Kutta Intearatlon was coded and the 
source code appears under the program name RUNGE, Some of 
the programs were extensively tested under an ADA-ED 
Interoreter, The linked list insertion program was written 
and tested in ADA-ED and the source code for it is under the 
program name LINK, The reader is warned that these two 
programs, RUNGE and LINK have not been tested under ADA-432 
and some modifications may be necessary to get them to 
execute . 
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CHARSl package soec i f i cat i on 



-- T^tis is the ADA soec i f i c at i on oackage for the 
-- CFA character search benchmark, 

— CHARSl 



pac kage SCh AR i s 

Subtype subint is integer range 1 
type txtarray is a r r ay ( I . , 256 ) of 
ar ray 1 / ar r av2 : txtarravf 

procedure ROFIL; 

procedure SE ARCH ( s rc h 1 en , a rg 1 en : 

ar ray 1 t ar ray2 ; 

I oc : 



end SCHAR; 



.256? 

character ; 



IN sub i n t J 
IN txtarray? 
OUT subint); 



-- CHARSl oackage body 



praqma envi ronment ( " ACS : TE X T I 0 . MLE" , " INTIO.MSE" , 

"SCHAR. MSE" ) ; 

with text<-iOfintio; use text*-iOfintiOfascii; 
oackage body SCHAR is 
Procedure RDFIL is 
line<-of«- input : strinaSO; 
char ; character? 
i / i : i nt eger ? 

begin 
s k i o ^ 1 i n e ? 
new*-line()? 

out*"1ine«-30("Enter Srch-strng/ S ends ") 

i: = l? 
j ; = 1 ; 

while i < 256 1 ooo 
1 i ne*-o f i nou t Get«-line**f'0()? 

exit when line*-of*'inout(l) - 'S'? 

for } in 1 . . 80 1 ooo 
exit when line'-of^-inoutlj) = ' ' and 

1 i ne<-o f «- i nout ( i + 1 ) = ' '? 

arrayl(i) := 1 i ne<*o f i nput ( i ) ? 
i : = i + 1 ? 
end looD? 
end 1 ooo ? 

fill array 2 
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n e w 1 i n e ( ) J 

out<- 1 i ne«-30 ( "Ent er Srch-ara» S ends ")» 

i := I ; 

while i < 256 1 ooo 
M ne<*o f i nout := Get«-H ne*-80 ( ) ; 

exit when 1 i ne<-o f <-i nout ( 1 ) = 
fori in 1..80 logo 
exit when 1 i ne<-o f *’i nout ( j ) = ' ' and 

1 i ne<-o f <• i nout ( j + I ) = ' 
appay2(i) := line^-of^-inoutCj); 
i ; = i + 1 ; 
end looo; 
end loooJ 

• checlc the appay's contents 

new^ 1 i ne ( ) ? 
fOP i in 1..80 looo 
out(aPpayl(i)); 
end looo? 
new«- 1 i ne ( ) ? 
for i in 1 . . 80 1 ooo 
out ( appay2 ( i ) ) ? 
end looo; 

out«-l ine«*10("end ROFIL " ) ; 
end RDFIL/ 

opocedupe SEARCH(sPCh1en,apolen : IN integer; 

array 1 , array2 : IN txtarray; 

loc : OUT inteaep) is 

i / i : i nt egep ; 
beai n 
i := 1 ; 
j := i; 
loc : = - 1 ; 

while i <= spchlen looo 
if appayl(i) = appay2(j) then 
if j+1 <= apqlen then 
i : = i + 1 ; 
i : = j + 1 »* 
else 

loc ; = i - j ; 
exit; 
end if; 
else 

i := i +1 ; 
j ; = 1 ; 
end if; 
end looo; 
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end search; 
end SCHAR; 

CHARSl driver routine 



oraqma environment ( ” ACS : TEXT 10 . MLE " / " IMTIO.MSE" r ’’SCHAR.MSE 

"MAIN.MSE" ) ; 

with text«-io^intio^schar; use text^-iofintio/schar^ascii; 



-- ROFIL and SEARCH contained in thesame oackage 
-- Timing also includes time for orocedure 

-- invocation. 

la Oct. 1982 

oackage body USER*-PROCESS«- 1 is 
orocedure MAIN is 

i » 1 oc f s rc h<- 1 eng t h , s rc h«-a rg f t i me r«- 1 ooD : inteoer; 

forever : boolean :=true» 
answer ; character; 



begin 

while forever looo 



-- initialize the arrays 

for i in 1 . . 256 1 ooo 
arrayl(i) := ' 
ar ray2 ( i ) : = ' ’ ; 

end looo; 



-- get the search arguments 
new*-line(); 

out*-30 ("Character search Q = Quits "); 

get (answer ) ; 

exit when answer =’Q'; 

RDFIL; 
new«- 1 i ne ( ) ; 

out<-30("Lenath of string to search?..."); 
get (srch«-length) ; 
new«* 1 i ne ( ) ; 

out ♦•30 ( "Lengt h of string to search for"); 
get ( srch<-arg) ; 
new«- 1 i ne ( ) ; 

out*-30(" Number of looos to time "); 
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get (t imer<*1ooD) ; 
new<* M ne ( ) / 

out*-20(" Start of Sea rc S » 

out ( BEL) ? 

for i in l.« timer<-1ooo 1 ooo 

SEARCHfsrch^-lenqth^srch^-arq/arrayl/arravEfloc); 
end looD? 
out ( BEL ) ? 
new«- 1 i ne ( ) ; 

out«-20("end tSe searcii "); 

new«- 1 i ne ( ) » 

Dut<-10("Location= ”); 
out ( 1 oc ) ; 
s k i o<- 1 i ne ; 
end looo; 
end MAIM; 

end USER«-PR0CESS*-1 ; 
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CHARS2 oacWaqe specification 



package SCHAR is 

type txtarrav is an rav ( 1 . . 256 ) of 
array 1 » appay2 : txtarray? 
procedure RDFIL; 

procedure SEARCH ( s rch 1 en / a rg 1 en : 

ar ray 1 / ar ray2 : 
1 oc : 



end SCHAR/ 



character? 



IN integer; 

IN txtarray? 
OUT i n t eae r ) ; 



-- CHARS2 Package body 



-• Timing prompts in the body of the search orocedure 

pragma envi ronmen t ( " ACS : TEX T 1 0 . mlE " , " I NT 1 0 . MSE " / 

"SCHAR. MSE" ) ? 

with text«-io/intio/ use text*-io/intio/ascii; 
package body SCHAR is 
orocedure RDFIL is 
1ine*-of<* input : strinqSO; 
char : character? 
i / j : i nteger ? 

begin 
s k i o 1 i n e ? 
new<- 1 i ne ( ) ? 

out*‘line«-30("Enter Srch-strng/ ? ends ")? 

i : = 1 ? 
i : = 1 ? 

while i < 256 1 oop 
1 i ne<-o f ♦- i nput := Get«-1 i ne«-60 ( ) ? 

exit when 1 i ne**o f ♦■i nout ( 1 ) = '$'? 
for j in 1..80 loop 
exit when line«-of«-inout(i) = ' ' and 

1 i ne«-of i nout ( j + 1 ) = ' '? 

arrayl(i) ?= 1 i ne*-o f i nout ( j ) ? 
i := i + 1 ? 
end loco? 
end loop? 

9 * 

f i 1 1 ar r ay 2 
new«" 1 1 ne ( 1 ? 

out<-1 i ne**30 ( "Ent er Srch-aro/ S ends ")? 

i ;= 1 ? 

while i < 256 1 ooo 
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1 i ne<-of ♦-i nput := Get«*l i ne«-80 ( ) ; 

exit when 1 i ne«-of ♦•i nput C 1 ) = '$'» 

for j in 1..80 loop 
exit when 1 i ne«-o f <-i nput C j ) = ’ ' and 

1 i ne ^"0 f «• i nput ( i + 1 ) = ' 
apray2(i) i~ 1 i ne*-of <-i nput ( j ) ? 
i : = i + 1 ; 
end 1 ooof 
end loop; 

•• check the array's contents 
end ROFIL; 



orocedure SE ARCH ( srch 1 en » a rq 1 en : IN integer; 

array I , arrav2 : IN txtarray; 

1 oc : OUT integer) is 

i / j ^ k / 1 i me r«- 1 OOP : integer; 

begin 

new«- 1 i ne ( ) ; 

out <-30 ( "Numbe r of 1 oops to time ” ) ; 

qe t ( t i me r«- 1 ooo ) ; 
new«-line(); 

out<-20(" Start of search '*); 

out (BEL) ; 

for k in 1 . , t i me r«- 1 oop 1 ooo 
i : = I ; 
j := i; 

1 oc : = - 1 ; 

while i <= srchlen loop 
if arrayHi) = array2(j) then 
if i+I <= arqlen then 
i : = i + 1 ; 
i := j+i; 
e 1 se 

1 oc : = i - j ; 
exit; 
end if; 
else 

i ; = i + 1 ; 
j : = 1 ; 
end if; 
end 1 ooo ; 
end loop; 
out ( BEL ) ; 

out<-20("end the search "); 

new«- 1 i ne ( ) ; 
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end search; 
end SCHAR; 

wm • 

-- CHARS2 driver routine 



pragma envi ronment ( " ACS : TEXT 10 . MLE ” / " I NT 10 . MSE " / " SCHAR . MSE " / 

"MAIN.MSE"); 

with text«-iofintio»schar; use text^-io^intiorscharfascii; 

-- RDFIL and SEARCH contained in the same package 

-- Timina is for the SEARCH only. Prompts are from 

the SEARCH orocedure 

la Oct. 1982 

package body USER«'PR0CESS<- 1 is 
procedure MAIN is 

i ^ 1 oc # s rc h<- 1 engt h , s rc h«-a rg : integer; 

forever : boolean ;=true; 
answer : character; 

beg i n 



out «-30 ( "chars2 with ^ gdo con f i gu ra t . . " ) ; 
new«-line(); 



while forever looo 

-- initialize the arrays 

for i in 1 . .256 1 ooo 
ar ray 1 ( i ) : = ' ' ; 

array2 ( i ) := ' ' ; 

end looo; 

-- get the search arguments 
new<* 1 i ne ( ) ; 

ou t «-30 ( "C ha r ac t e r search Q = Quits 

get (answer ) ; 

exit when answer ='Q*; 

rofil; 

new«-1 ine(); 

out«-30 ( "Lengt h of string to search?..."); 

get (srch<*1ength) ; 

new<-line(); 
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put ♦■30 ( "Lencjt h of strinq to search for")? 
get ( s PC h^-arq ) ; 
new^- 1 i ne ( ) f 

SEARCH(srch*"lengthfSPch^‘ara/arravl »array2f loc) 
out ♦■ 1 0 ( "Loca t i on= "); 

Put ( 1 oc ) f 
sk i D«-l i ne; 
end loop; 
end MA IN ; 

end USER4-PR0CESS^-1 ; 
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--QUICK1 packaqe specification 

-- QUICKSORT package specification (Iterative) 

package QUICKSORT is 
t yoe item is 
record 

key : integer; 

data : character; 
end record; 

type inarray is array(1..20) of item; 
procedure S0RT(arg : IN OUT inarray); 
end QUICKSORT; 



-- QUICKl package body 

-- QUICKSORT oackaqe body (Iterative) 

pragma environment ( " 4C S : TEXT 1 0 . MLE " , " I NT 1 0 . MSE % 

"QUICK. MSE") ; 

with text«-iOfintiOf quicksort; 
use t ex t <- i o f i n t i o f ou i c k so r t ; 
package body QUICKSORT is 
Procedure S0RT(arq : IN OUT inarray) is 
m : const ant : = 20 ; 
i f j » 1 / r : i nt eqer ; 

m i d<-ot / t emp : item; 

tyoe stack«"frame is 
record 

1 f r : i nt eqer ; 

end record; 

stack : array(l..m) of s t ac k«- f rame ; 
s : i nt eaer ; 

Bea i n 
1 : = 1 ; 
r := 20; 
s : = 1 ; 

stack(l).1 := i; 
stack(l).r := 20; 

1 ooo 

1 := stack(s).1; 
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r := stack(s) . r» 
s : = s- 1 f 
1 OOP 
i : = 1 ; 
j : = r ; 

mid<-Pt := arg ( ( 1 t r ) /2 ) ; 

1 OOP 

while arg(i).key < mid«-Pt.key loop 
i : = i + 1 ; 
end 1ooP» 

while mid*-ot.key < arq(j).key loop 
i := j-i; 
end loop? 
if i <= i then 
t emp := apg(i)f 
arg{ i ) := arg( j 1 ; 

arq ( j ) : = t emp? 

i : = i 1 1 ; 
j := j-i; 
end i f ; 

exit when i > j » 
end loop? 
if i < p then 
s : = s+ 1 ; 
stack(s).l := i; 

St ac k ( s ) . p : = p ; 
end if; 

P : = j ; 

exit when 1 >= p; 
end loop; 
exit when s = 0; 
end loop; 
end SORT; 
end QUICKSORT; 



QUICKl dpivep poutine 

a 

-• QUICKSORT oackage body for Driver (Iterative) 

opagma envi ronment ( " ACS : TEXTIO . mlE" , "QUICK .,MSE" , 

"INTIO.MSE","MAIN.MSE") ; 
with quicksopt/text»-io»intio; 
use quicksoPtftext«-iO/intio»asci i ; 
package body USER^-PROCESS*- 1 is 
opocedupe MAIN is 
apqrtemo*-appay ; inappay; 
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i , 1 oop+*va 1 f j : integer; 

data : boolean := true; 

Begin 

for i in 1 . .20 1 ooo 

arg( i ) , key 0 ; 
arg(i).data 'a'? 
end loop? 

new«- 1 i ne ( ) » 

out«-1 ine«*20("QUlCKsORT BENCHMARK 
out«*l ine*'20("Iterat ive Version. . .'*) » 
out «*20 ( ”£nt er key > followed "); 
out*"20("immediate1y by datar''); 

out «• 1 i ne«-20 ( " 0 ter-ninates ” ) ; 

new«* 1 i ne ( ) ? 
i : = 1 ; 

while data 1 ooo 
get (arg( i ) .key ) 7 
exit when arg(i).key = O; 
s k i p+- 1 i ne/ 
get (aro (’i ) .dat a ) ; 
i : = i + 1 ; 
s k i o 1 i n e ; 
end loop; 
new<- 1 i ne ( ) ; 

out ♦* 1 i ne** 1 0 ( " You r Input")* 
for i in 1 . .20 1 ooo 
out(arg(i).key)* 
out(arg(i).data); 
new«- 1 i ne ( ) ; 
end loop* 

Loop 

out<-30(” Number of loops to time ")* 

get ( 1 ooo«-va 1 ) ; 

exit when (looo«*va1) = 0* 
new«-1 ine()* 
for i in 1..20 1 ooo 
t emo^-a r r ay ( i ) . k ey := arq(i).key* 
t emo«-ar ray ( i ) . dat a := ara(i).data; 
end 1 ooo * 

ou t «-20 ( " S t a r t of Quicksort.."); 
out (be 1 ) ; 

for i in I . . ( 1 ooo*-va 1 ) 1 ooo 

for j in 1..20 looo 
arg(j).key := t emo<-a r r ay ( j ) . key ; 
arq(j).data ;= t emo«"a r ray ( j ) . da t a ; 
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end loop; 

SORT ( a pg ) ; 
end loop; 
out (be 1 ) ; 
new*- 1 i ne ( ) ; 

out H ne^-JO ( "End the Quicksort..."); 
out*- H ne*’ 1 0 ( "The Output"); 
for i in 1..20 1 ooo 
out(ara(i).key); 
out(ara(i).data); 
new* 1 i ne ( ) ; 
end loop; 
end Looo; 
end i'^AIN; 

end USER*PR0CESS*1 ; 
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QUICK2 



Dackage soec i f i cat i on 



QUICKSORT package soec i f i cat i on (Recursive) 

package QUICKSORT is 

type i t e (Ti is 
record 

key t i nt eger » 
data : character? 
end record? 

tyoe inarray is arr a y(l,. 20) of item? 
subtype subint is integer range 1..20? 

procedure SORT ( 1 e f t / r i gh t : in subint? 

ara : in out inarray)? 

end QUICKSORT? 



-- QUICK2 package body 

-• QUICKSORT package body (Recursive) 

pragma envi ronment ("4CS:T£XTI0.MLE'‘ r "INTI0.'^SE"f 

"QUICK. MSE”) ; 

with text<-io/intio» quicksort? use text<-io/intio/guicksort 

package body QUICKSORT is 

procedure SOR T ( 1 e f t » r i gh t : in subint? 

arg : in out inarray) is 

i f j ? subint? 
mid<"Ot/temo ? item? 

Begin 

i : = left? 
j : = right? 

mid«-Pt := arg ( ( 1 e f t + r i gh t ) /2 ) ? 

1 OOP 

while arg(i),key < mid^-ot.key loop 
i : = i 1 1 ? 
end loop? 

while mid<*ot.key < arg(j).key looo 
j := j-l? 
end looo? 
if i <= i then 
t emo : = aro ( i ) ? 
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arq(i) := arq(j); 
ara( j ) := temp; 

i := i-H; 
j : = . j - 1 ; 
end if; 

exit when i > j; 
end loop; 
if left < j then 
SORT (left» i»arq); 
end if; 

if i < right then 
SORT (i /riqht»ara) ; 
end if; 
end sort; 
end QUICKSORT; 



--QUICK2 driver routine 

-- QUICKSORT oacl<age body for Driver (Recursive 

pragma envi ronment ("ACSlTEXTIO.MLE”/ "QUICK.MSE"/ 

"INTIO.MSE", "MAIiM.MSE") ; 
with quicKsort»text«-i' 0 /intio; 
use guicKsort/text^'io / int io»asci i ; 
package body USER«-PROCESS<- 1 is 
orocedure IN is 
arpf temo^-array ; inarray; 

1 e f t ♦* i ndex / r i qh t i nde X r subint; 
i / 1 ooP<*va 1 / i J integer; 
data : boolean ;= true; 

Beg i n 

for i in 1 . .20 1 ooo 
arg(i),key ;= 0; 
arq(i).data := 'a'; 
end loop; 

new«- 1 i ne ( ) ; 

out<-l ine«-20("QUlCKSORT BENCHMARK "); 
out <‘20 ( " En t e r key» followed ” ) ; 
out <-20 ( " i mmed i a t e 1 y by data/"); 

out<-line<‘20(" 0 terminates "); 

new<> 1 i ne ( ) ; 
i : = 1 ; 

while data 1 ooo 



qet ( apq ( i ) . key ) > 
exit when arq(i).key = O; 
skio«-l i ne? 
qe t ( a pg ( i ) . da t a ) ; 
i : = i 1 1 ; 
sk i o«-l i ne? 
end looD? 
new«-1 ine()? 

out «*1 i ne«-l 0 ( " You P Inout")? 
f OP i in 1 , , 20 1 ooo 
Dut(apq(i).key)» 
out(apg(i).data)» 
new^*! i ne ( ) » 
end 1 ooo i 

Loop 

out«-30("# of looos to time?..0 exits ")* 
get ( 1 ooo<-va 1 ) ? 

exit when (looo^-val) = 0; 
new^l ine()» 
f OP i in 1 . . 20 1 ooo 
temo^-ap Pay ( i ) . key := aPo(i).key/ 
t emp«-ap pay ( i ) . da t a i- aPo(i).data/ 
end looo; 

out«-20 ( "StaPt of Qu i c ksoPt . . " ) ; 
out (bel ) ; 

fop i in 1 , . ( 1 ooD«-va 1 ) looo 
f OP i in 1 . . 20 1 ooo 
apg(j).key := te^D+*appay ( i ) .key; 
apg(j).data := t emo^-ap pay ( i ) . dat a ; 
end looo; 

1 e f t <- i ndex : = 1 ; 
piqht«- index := 20; 

SORT ( 1 eft^-i ndex» piqht<-i ndexfapq) ; 
end 1 ooo ; 
out ( be 1 ) ; 
new*- 1 i ne ( ) ; 

out* 1 i ne*-20 ( "End the Qui cksoPt . . . " ) ; 
out*l ine*10("The Outout") ; 
foP i in 1..20 1 ooo 
out(apq(i),key); 
out ( apq ( i ) . dat a ) ; 
new*1 i ne ( ) ; 
end looo; 
new*1 i ne ( ) ; 
end Loop; 
end main; 

end USER*PR0CESS*1 ; 
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-- HASHl oackage soec i f i cat i on 

package HASH is 

size t integer := 10? 

table : array(0.,9) of integer? 

function HASHES(key t IN integer) return integer? 
end HASH? 



-- HASHl oackaqe body 

pragma en v i ronmen t ( " ACS : TEX T 1 0 . MLE" , - I NT 1 0 . MSE " , " H ASH . MSE " ) 

with text<-iorintio? 

use text**iofintiorascii? 

oackage body HASH is 

function HASHES(key : IN inteaer) return integer is 

chec k » i : i nt eger ? 

Begin 

-• comoute the first olace to look 
check := key mod size? 
for i in 1,. size/2 1 ooo 
if table(check) = key or table(check) = 0 
then 

return check? 
else 

check := (check+i) mod size? 
end i f ? 
end loop? 
return 0? 
end HASHES? 
end HASH? 



-- HASHl driver routine 

-• hash table search benchmark 
hashl.eod on disk 

““ timing includes orocedure invocation overhead 

oragma envi ronment ( " ACS : TEX T 1 0 . VLE" , " I N T 1 0 . MSE " , " H ASH . MSE ” , 

••MAIN.MSE'' ) ? 

with text<-iOrintiorHASH? 

use text<-iorintio»HASH,ascii? 
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package body user«-process«-l is 
procedure main is 

t i me r«> 1 OOP » pos i t i on # key / j J integer; 
answer : character; 

forever : boolean := true? 



beg i n 

new^-lineC)? 

ou t ^20 ( "HASH 1 benchmark....."); 



fill the hash 

t ab 1 e ( 0 ) 
t ab 1 e ( 1 ) 
tabl e(2) 
t ab 1 e ( 5 ) 
t ab 1 e (^ ) 
tab 1 e ( 5 ) 
t ab 1 e ( 6 ) 
t ab 1 e ( 7 ) 
t ab 1 e ( 8 ) 
tabl e(9) 

.yhile forever 



table with CFA 

;= o; 

:= 183 ; 

;= 1 1 ; 

;= 1035 ; 

;= 1035 ; 

;= 183 ; 

:= 86 ; 

;= O; 

;= 183 ; 

;= 183 ; 

1 OOD 



sampl e entries 



new *-1 ine(); 

out «-20 ( "Cont i nue? QJ guits."); 

get (answer) ; 

exit when answer = 'Q'; 

new <- 1 i ne ( ) ; 

out«- 20 ("enter an integer key"); 
get ( key ) ; 

new^line()? 

out «-30 ( "number of looos to time ")7 

get(timer«-looo); 

new«* 1 i ne ( ) 7 

out «-20 ( " St art hash lookuo ...")7 
out (be 1 ) 7 



for j in l..timer<-looD looo 
Dosition := HASHES(key)7 
end loop? 
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out (be 1 ) ? 
new«- H ne ( ) » 

out<-20 ( "end of hash lookuo..")? 
new<- 1 i ne ( ) » 

out<-20 ( "hash oosition = 
out (oos i t i on ) f 
sk i D«-1 i ne ; 

end loooJ 

new«* 1 i ne ( ) ? 

out«'30("end of HASH table lookuo 

end main? 

end user«-orocess<- 1 ? 
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-- DCOMl oackage soec i f i cat i on 

Digital Communication Processing Program 



— 19 Oct 82 

oraqma envi ronment ("ACStTEXTIO.MLE ") 7 
with text«"io 7 use text^-io? 

Package DIG<-C0M is 
c 1 : const ant : = 10; 

c2 : constant := tO; 

subtvoe dest<-tvoe is integer range l..cl; 
subtyoe con«- i d«-t voe is integer range l..c2; 
tyoe message; 

type message^-otr is access message; 
t yoe message i s 
record 

dest i nat i on 
connec t i on 
size 
data 
end record; 

subtyoe buf«-index is integer range l..c2; 
tyoe buf«-tb1 is array(l..c2) of buf<*index; 
tyoe buf4-tbl<-otr is access buf«-tbi; 
dest i nat i on*-tb 1 t array(l..cl) of bu f t b 1 «-o t r ; 
buffer«-array 7 array(l..c2) of string30; 



dest«-tyoe; 
con<- i d<-t yoe 7 
i nteoer ; 
s t r i ng30 ; 



orocedure forwardCmsg: IN message«-ot r ) ; 



end DIG4-C0M; 



-- DCOMl oackage body 

pragma envi ronment ("ACSiTEXTIO.^^LE”/ "DCOM.MSE" , ’’ I NT 1 0 . MSE " ) 
with text<-iO/intio 7 use text^io/intio/ascii; 

oackage body DIGICOM is 

Procedure forward(msg : IN message<-ot r ) is 
i / j : i nt ege r 7 
buf f er«-i ndex ; buf<-index; 
line ; bu f <-t b 1 <*ot r ; 
buf«-array : buf<-tbl; 
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begi n 



line := des t i na t i on«>t b 1 (msq . des t i na t i on ) ; 
buf«*arrav := line. all; 
i : = 1 ; 

while bu f <-a r Pay ( i ) /= msa. connect i on 1 ooD 
i := i + 1 ; 
end_ 1 OOP? 

bufter^-index :=buf**arravCi); 
bu f f er<-a p ra V (bu f f e r<- i ndex ) := msq.data; 

end fopwapd; 
end OIG^-COM; 



DCOMl dpivep poutine 

mm mm 

“• digital communication benchmapk 
0C0M12.E0D on disk 

-• timing includes opocedupe invocation overhead 

26 Oct 1982 

pragma envi ronmen t ( " ACS : TEX T 10 . «LE " » " I NT 1 0 . MSE " / DCOM . MSE " , 

"main.mse" ) ; 

with t ex t i o / i n t i o / DIG**C0M; 
use text<*io»intio»0IG**C0M,asci i ; 

package body user«'PPocess** 1 is 
procedure main is 
i » j : i n t ege r » 
timer<-looo J integer; 
k ; buf i ndex ; 

buf <-tabl e<*Pt r : buf «-tbl «-ot r ; 

msg**out : messaoe<-ot p ; 
forever : boolean := true; 
answer : character; 

beg i n 

out<-30 ( "chars* . 4 gdp configuration...'*); 
ne w«* 1 i ne ( ) ; 

out «■ 30 ( " t i m i ng includes oroc ovhd "); 

initialize the destination table 
new<- 1 i ne ( ) ; 
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out«-30 ( " i n i t destination table '* ) ; 

for i in l..cl 1 ooo 
dest i nat i on<*t b1 ( i ) := new buf«-tbl; 

end looof 

-- initialize all buf«-tbl*s 
new** 1 i ne ( ) ; 

out «-30 ( " i n i t buf*-tbl's "); 

for i in l,,cl 1 ooo 

buf ♦•t ab 1 e*"Ot r := des t i na t i on+-t b 1 ( i ) ; 
for ] in l..c2 1 ooo 

bu f «-t ab 1 e«-Dt r ( j ) := j; 

end 1 ooD ? 
end looDf 

initialize buffer 

m • 

new«- 1 i ne ( ) f 

out ♦•20 ( '* i n i t the buffer "); 

forkinl..c2loOD 

bu f f e r«-ar r ay ( k ) := " 

en d 1 ooo 7 

new<- 1 i ne ( ) ? 
while forever loco 

out+'l 0 ( "cont i nue? " ) 7 

get (answer) 7 

exit when answer ='N'; 

(nsq^-out := new message? 
msg«-ou t . s i ze i- 0? 
new<- 1 i ne ( ) ? 

out «-20 ( " St a r t digit comm.,..")? 
n e w ♦• 1 i n e ( ) ? 

out<-50("enter destinationf conn^data..")? 
get(msg«-out. destination); 
sk i D<- 1 i ne ; 

get (msg«-out .connect i on) 7 
s k i 1 i ne ? 

msg^-out . da t a : =get ♦•! i ne<-30 ( ) ? 
new*- 1 i ne ( ) ? 

out ♦-30 ( "number of looos to time ")? 

get ( t i mer<- 1 ooo ) 7 
Dut<-10 ( "sendi ng, , . " ) 7 
out (bel ) ? 

for i in l..timer<'looo looo 
forward(msg<-out ) 7 
end looo? 
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ou t ( be 1 ) ? 

ou t «-20 ( " . . . done sending ") 

new«-1 ine()/ 

out<-20("buffer flush is..,..") 
for k in l..c2 1 ooo 
out ( k ) ; 



put«-l ine<-30(buffer«-array(k)) 
new**! i ne ( ) f 
end Iood; 
s k i o*- 1 i ne / 
end Iood; 
new<-)ine(); 

out<'20(”end of decoiil ”); 

end main; 

end use r«*oroc es s«- 1 ; 




r 






0C0M2 Dackaqe soecification 



-* Digital Communication Processing Program 



— 19 Oct 62 

pragma envi ronment ("ACStTEXTIO.MLE" ) 
with text«"io / use text^-io; 

Package DIG*-C0M is 
cl : constant := 10; 
c2 : constant := 10; 
subtyoe dest+-tvoe is 
subtyoe con*-ia*-tyoe i 
tyoe message; 



i n t ege r range 1 . 
s i n t ege r range 



c 1 

1 . 



C 2 



is access message; 



type message«-otr 
tyoe message is 
reco rd 

destination 
connect i on 
size 
data 
end record; 

subtyoe buf<-index is integer ranae l..c2; 
tyoe buf«-tb1 is array(l..c2) of ouf*- index; 
tyoe buf*-to1+-otr is access buf«-tbi; 
destination«-tb1 : arrav(l..cl) of buf«-tb1<-otr 
bu f f e r«-a r ray ’ array(l..c2) of strinq30; 



de s t «-t yoe ; 
con<-id^-tyoe; 
integer; 
stringSO; 



orocedure forwardCmsg: IN messaqe*'Otr); 

end DIG«-C0M; 



•• 000*^2 Package body 

oragma envi ronment ( " A CS : T EX T T 0 . MLE " , ” DCOM . msE ” , " I N T 1 0 . ^SE " ) ; 

with text<-iO/intio ; use text«-iOfintiO/ascii; 

package body 0IG<-C0M is 

orocedure forward(msg ; IN messaoe«-otr) is 
i / J : integer; 

timer«*1ooo : integer; 

buffer*- index : ouf«-index; 

line ; buf*-tbl«-Dtr; 
buf*-array t bufrtoi; 
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I 



begi n 



new<- 1 i ne ( ) ; 

put<-30 ( "number of looos to time "); 

get ( t i mer+-1 ood) ; 

Dut**10("sending. . ,") ; 
out (be 1 ) / 

for j in 1 . . t i me r «- 1 ooo 1 ood 

line t= desti n at ion<-tb1(msg. destination); 
buf«*arrav := line. all; 

1 • — i f 

while buf«-array(i) /- msa. connection looD 
i ; = i + 1 ; 
end 1 ooo ; 

bu f f e r i nde X ;= buf «-ar ray ( i ) ; 
bu f f e r<-a r ray ( bu f f e r<- i nde X ) := msg.data; 

end loop; 

Dut(bel); 

DU t «-2 0 ( " , , , done sending "); 

new«-line(); 
end forward; 
end DIG<-C0M; 



-- OCQMJ driver routine 
-- digital communication benchmark 
DCOM’S! .EOO on disk 

timing does not include orocedure invocation overhead 
26 Oct 1982 

pragma env i ronment ( M C S : TEXT 1 0 . MLE " / " I NT 1 0 . MSE " / " DCO^^ . MSE % 

"vaiN.v^SE") ; 

with text«"io>intio» 0IG<-C0^; 
use text«-io,intio»DIG«-COM,asci i ; 

oacicage body use r ♦-o r oc es s«- 1 is 
procedure main is 
i/j ; integer; 
k : Duf<-index; 

bu f <-t ab 1 e«-ot r : bu f <• t b 1 <-o t r ; 

msg<-out : message<-ot r ; 
forever : boolean ;= true; 
answer : character; 
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begin 

DU t <-30 ( "c h a r s * . ^ gdp configuration..."); 
new<-l i ne ( ) ; 

DU t ♦•30 ( " t i m i ng does not include oroc..")/ 
initialize the destination table 
new<-l ine(); 

Dut<-50('*init destination table "); 

for i in l..cl looo 
destination<-tbl(i) t= new buf<-tbl; 
end looo; 

initialize all bufwtbl's 
new<-1ine(); 

out«-30("init buf<-tb1 's.. 

for i in 1 . . c I 1 ooo 

bu f <- 1 ab 1 e*-o t r := de s t i na t i on<- 1 b 1 ( i ) ; 
for j in l..c2 1 ooD 

buf<-tab1e<-Dtr(j) ;= j; 
end looo; 
end looo; 

““ initialize buffer 
new<-1ine(); 

Dut<-20("init the buffer....."); 
for k in l..c2 looo 

buf f er<-ar ray C k ) := " 

end 1 OOD ; 

new«-1ine(); 
while forever looo 
DU t <- 1 0 ( "c on t i nue? 
get (answer) ; 
exit when answer ='n'; 

•nsg*-out := new messaae; 

•nsg«-out .size 0 ; 
new<-1ine(); 

out<-20("start digit com ■«...."); 
new<- 1 i ne ( ) ; 

out<-30("enter oestination^ conn^data.."); 
get (msg<-out .dest inat i on) ; 
s k i D<- 1 i ne ; 

get (msg<-out .connect ion) ; 
s k i o<- 1 i ne ; 

msg<-ou t . da t a : =get <- 1 i ne<-30 ( ) ; 



1 Oa 



forwardCmsg^-out ) i 

ou t <-20 { " bu f f e p Hush is ") 

for k in 1 . .c2 1 ooo 
put ( k ) ? 

put<-l ine<-30(buffer<-array(k) ) 
ne w<- H ne ( ) / 
end loop# 
ski D<-1 i ne# 
end Iood; 
new*-! ineC) ? 

put<-20("end of decoml ")* 

end main; 

end user<-orocess«-l; 
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-- v)EMl packaqe soec i f i c a t i on 

-- MEMl recursive memory test package soec i f i ca t i on 

pragma envi ronment ("ACS:TEXTIO.MLE") ; 
with text*-io; use text«-io; 
package EAT*-MEMORY is 
size ; constant := 50; 
i : integer :=0; 

tyoe smal1*-tab1e is array(l..size) of character; 
type sma 1 1 <-t ab 1 e<-Pt r is access sma 1 1 ♦-t ab 1 e ; 

procedure FOREVER; 
end EAT<-MEM0RY; 



--MEM1 Package body 

-- mEMI recursive memory test body 

pragma envi ronment ( " ACS : TEX T 1 0 . MLE " , "EAr.iMSE" , " INTIO.MSE" ) ; 
with intio/text«-io; 
use intio/text<-io; 

package body EAT«-ME'^0RY is 
Procedure FOREVER is 

table*-otr : sma 1 1 ♦- 1 ab 1 e*-o t r ; 

beg i n 

i : = i + 1 ; 

DU t ( i ) ; 
new«*1 ineC); 

table*-ptr ;= new sma 1 ) <-t ab 1 e ; 

FOREVER; 
end FOREVER; 
end EAT<-MEM0RY; 



-- ^EMi driver routine 

-- MEMI recursive memory test driver routine 

pragma envi ronment ( " AC S : TEX T I 0 . mlE " , "EAT .mse" , 

-maIN.MSE" ) ; 

with t e X t <■ i o f E A T<"MEM0R Y ; 
use text<-io»EAT<'ME'^ORY; 
oackage body user^-orocess^ 1 is 
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D roc edu re main is 



beg i n 

put«-30(" start of eat memory 
FOREVER; 
end main; 

end user^-orocess^* 1 ; 



107 



f 







-- mEM 2 oackage soec i f i cat i on 

-- MEM2 interative mennory test oackage soec i f i c a t i on 

0 r agma envi ronment ("ACStTEXTIO. MLE " ) / 
with text<-io/ use text«-iOf 
package EAT«-mEMORY is 
size : constant := 50; 
i : integer :=0; 

type sma11*-table is array ( 1 , .si ze) of character; 
t yoe sma 11 <- 1 ab 1 e<-D t r is access sma 1 1 «-t ab 1 e ; 

procedure FOREVER; 
end EAT«-M£morY; 



-- MEM2 oackage body 

mm 

-- '^EM2 interative memory test body 

or agma envi ronment ( " ACS ; TEX T 1 0 . MLE " , " E A T . MSE " , " I MT 1 0 . MSE " ) ; 
with intio»text«-io; 
use intio/text«-io; 

package body EAT«-MEM0RY is 
procedure FOREVER is 

table«-otr ; sma 1 1 ►t ab 1 e<-ot r ; 
infinite : boolean :=true; 
begin 

while infinite looo; 
i : = i + 1 ; 
pu t ( i ) ; 
new*-l ine() > 

tab1e*‘Otr := new small^tableJ 
end loop; 
end FOREVER; 
end EAT<-meMORY; 



-- MEM2 driver routine 

-- ME M2 interative memory test driver routine 

M mm 

or agma envi ronment ("ACSrTEXTIO.MLE", "E AT .MSE" , 

"MAIN.MSE" ) ; 

with text«-io>EAT*-MEiMORY; 
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use t e X t i o f E A T+-MEMORY ; 
package body usep«-process«-l is 
procedure main is 

beg i n 

put«-30(" start of eat memory 
FOREVER; 
end main; 

end use r«-oroce s 1 ; 
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SEARCH 



-• Courtesy Prof. Patterson,Computer Science Division/ 

Department of Electrical EnQineering i Computer Sciences 
Univ. of California, Be r ke 1 ey , C A , 

pragma envi ronment ( " ACS : TEXT 10 , MLE " / " INT ID .MSE " , "MAIN.MSE") 

with text*-io/intio, 

use text«-io/intio/ascii? 



package body USER«-PR0CESS<- 1 is 
procedure MAIN is 
type strin is a r r ay ( i n t eoe r 
num i t er at i ons : integer; 

pos i t i on , ns / nk : integer; 

S/k : strin; 



range 1..120) of character. 



function STRSCH(s,k ; 

ns , nk 

i , j : i nteger ; 

base , k s a ve , c on t : integer; 

kend/ssave : integer; 

r ; i n t ege r ; 



IN strin; 

: IN integer) 



return int ege r i s 



beg i n 

base ; = 1 ; 

ksave : = 1 ; 

cont := ns-nk+base; 

kend := ksave + nk-i; 

i ; = 1 ; 

j != 1 ; 

<<tOP>> 

while s(i) /= k(J) loop 
if i >= cont t hen 
r : = - 1 ; 
goto finish; 
end if; 
i ; = i 1 1 ; 
end loop; 
ssave : = i ; 

J j+i; 

while i <= kend loop 
i : = i + 1 ; 

if s(i) /- k(j) then 
i ; = ssave t 1 ; 
j : = ksave ; 
goto top; 
end i f ; 



% 




i 




1 



ti 




base + 1 ? 



j := j+i; 
end looo; 
p t = ssave ” 

<<finish>> 
return ( r) J 
end STRSCH; 

Beg i n 

s(1..60) := "000000000000000000000000000000000000 

000000000000000000000000 " ; 

s(61..120) ;= "HEREOOOOOOOOOOOOOOOOOOOOOOOOOOHERE 

IS A MATCHOOOOOOOOOOOOOOO"; 
k(1..60) := "HERE IS A MATCH 

H • 

f 

k(61 . . 120) ;= " 

II • 
f 

1 OOD 

Dut«'Hne*-50("Berl<e1ev Character Search "); 

put<-30("# of 1 ooDs to ti'Tie?..0 Exits "); 
getCnum iterations); 

exit when num i t e r a t i ons = O; 
ne w<- 1 i ne ( ) ; 
ns : = 120; 
nk ; = 15; 
out (be 1 ) ; 

for i in 1 . . nuii i t e r a t i on s looo 
Dosition := STRSCH (s / k / ns f nk ) ; 
end looo; 
out ( be 1 ) ; 

out<-l ine«-10("ENO SEARCH"); 
out (oos i t i on ) ; 

end looo; 
end MAIN; 

end USERoPROCESS<-l ; 
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SIEVE 



Courtesy Prof. Patterson/ Computer Science Division 
-- Department of Electrical Engineering S Computer Sciences 
-- University of California/ Berkeley CA. 

pragma environment ( " ACS : TEXT 1 0 . MLE ” / " I NT 1 0 . MSE " / 

"main.mse" ) ; 

with text**io/intio7 
use text*-io/intio/asci i 7 
package body USER<-PROCESS«- 1 is 
Procedure ^AIN is 
size : constant integer ;= 2007 
flags : a r r ay ( 0 , , s i ze ) of boolean7 
or i me / k / count / 1 ooo«-va 1 : integer? 

Beg i n 
loop 

Dut<'30(’*# of loops to time?..0 exits '')7 
get ( 1 ooD*-va 1 ) 7 
exit when looo<-val = 0? 
new*"! ine()7 
out (be 1 ) 7 

for iter in inteaer range 1 . . ( 1 ooo«-v a 1 ) loop 
count ; = 07 
for i in 0.,size 1 ooo 
flags(i) ;= true7 
end looo7 

for i in 0..size 1 ooo 
if f 1 ags ( i ) then 
prime i + i + 3? 
k ; = i + or i me 7 
while k <= size loop 
flags(k) ;= false7 
k ;= k t orime7 
end looo7 

count ; = count + 1 7 
end i f 7 
end 1 ooo 7 
end looo7 
ou t (be 1 ) 7 

ou t 1 i ne+- 1 0 ( " End Sieve")7 
ou t ( c oun t ) 7 
out^'lOf" Primes ")7 
new<- 1 i ne ( ) 7 
end loop? 
end MAIN? 

end USER«-PR0CESS4>1 7 




i: 

ii; 
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ACKER 



-- Courtesy Prof. Patterson/Computer Science Division, 

-- Deoartment of Electrical Enqineering S Comouter Sciences 
-• Univ. of California# BerkelevrCA. 

pragma environment ( " ACS : TEXT 10 . MLE” / " INT 10 . MSE" , "MA I N . MSE" ) 

with text*-io,intio/ 

use t e X t i o # i n t i o , a sc i i / 

package body USER«'PR0CESS«' t is 
orocedure MAIN is 
a,i,arql,arq.? : integer? 

function ACKER (x,y : IN integer) return integer is 

beg i n 

if X = 0 then 
return (y+1)? 
elsif y = 0 then 

return ACKER ( x - 1 , 1 ) ? 
else 

return ACKER ( x - 1 , ACKER { x , y- 1 )) ? 
end i f ? 
end ; 

Begi n 

out<-line<-20("Ackermann Benchmark '*)? 
out <- 1 i ne«-20 { " To Exit, Enter 0 ” ) ? 

Du t <- 1 i ne<-30 ( " Beg i n time when bell sounds ** ) ? 

1 OOD 

ou t 1 i ne<- 50 ( " En t e r ACKER Aguments " ) ? 

get ( a rg 1 ) ; 

exit when a rg I = 0 ? 
sk io<-l i ne? 
get ( a rq2 ) ? 

DU t ( be 1 ) / 

a ?= ACK ER ( a rg 1 , a r g2 ) ; 
ou t ( be 1 ) / 

out «- 1 0 ( "Out out of ")? 

ou t ( a r g 1 ) ? 

out ( • , ' ) ; 

out ( arg2 ) ? 

new<- 1 i ne ( ) ? 

DU t ( a ) ? 
new«- 1 i ne ( ) ? 
end looD? 
end MAIN? 

end USER<-PR0CESS<-1 ? 
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APPENDIX D 



CFA BENCHMARK ALGORITHMS 

The twelve benchmark program algorithm descriptions 
used In the first CFA study follow, A more detailed 
discussion of these can be found In Reference 8, 

1, I/O INTERRUPT KERNEL, FOUR PRIORITY LEVELS 

The Interrupt kernel will be activated by an I/O 
interrupt with priority level 0,1,2 or 3 from one of four 
devices. Actual Interrupt processing will be simulated by 
counting the occurrences of each type of Interrupt, Higher 
level interrupts will be aole to preempt processing of lower 
priority interrupts. The interrupt handler must provide for 
resumption of processing of the preempted lower level 
interrupt from the point of preemption. As much processing 
as possible will be done wltn higher priority I/O interrupts 
enabled , 

2, I/O INTERRUPT KERNEL, FIFO PROCESSING 

The Interrupt kernel will be activated by an I/O 
interrupt from one of four devices which will be Placed In a 
service queue for flrst-ln-first-out (FIFO) processing. 
Actual Interrupt processing will be simulated by counting 
the occurrences of each type of Interrupt. Space should be 
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provided to handle at least ten queued Interrupts at one 



time. 



3. INPUT/OUTPUT DEVICE HANDLER 

After an I/O request is issued by an application 
proqram, and after the executive queues an input control 
blocK , this test program is initiated and it performs the 
following actions: 



1, Chec!< status of the tape drive. If device is busy 
exit. If the device is not operable branch to an 
error routine, if the device is available, set up 
and initiate the requested transfer, 

2, After completion of the transfer, and a conse- 
quent interrupt, the device handler is reentered 
and the following processing is performed: 

a. Store status information (device type and 
identification ) . 

b. If transfer was unsuccessful, abort further 
processing. 

c. If a successful transfer occurred and all re- 
quested transfers accomplished then exit. 



The application programs perform high level logical I/O 
calls that cause the queuing. 



4, FAST FOURIER TRANSFORM 

The following variables are used in the algorithm: 

N; The number of data points 0<= n <= 2**16, 

X: A vector holding the N samples as complex 

numbers . 

W: A vector holding the first N/2 powers of EXPC- 
2»pi*i»/N) . 

Work: Auxiliary working storage. 
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procedure FFT(N,X,W) 

GROUPS ;= N 

do for PASS ;= 0 by steps of 1 until 

lo<32 Cn)-1 

do for all ELEMENT such that 

0 <= eleipent <= N/2 
"Generate complex addend" 

WEXP ;= 0 
if PASS > 0 

then WEXP ;=( (ELEMENT»N)/2) / 
2»*PASS) MOD (N/2) 

end-if 

if WEXP <> 0 

then TFMPl := X (ELEMENT+N/2 ) ♦ 
W(EXP) 

else TEMPI ;= X (ELEMENT+N/2) 
end if 

"generate 2 element entries 
in data vector" 

XKELEMENT) ;= X(ELFMENT) + 

TEMPI 

XKELEMENT + N/2) X(ELEMENT) - 

TEMPI 

end"do 

if PASS < Clog2(N) - 1) 
then 

"execute perfect card shuffle 
on data vector" 

P J= 2*»PASS 
GROUPS := GHOUPS/2 
do for all I such that 

0 <= I < GROUPS 
do for all J such that 

0 <= J < P 

INDEXl ;= 2*P*I •)> J 

INDEX2 := P*I *J 

X(INDEXl) ;= XKINDEX2) 
XCINDEXl+P) := XI (INDEX2 + N/2) 
end-do 
end-do 

else 

do for all I such that 0 <= I < N 
X ;= XKI) 
end-do 
end-lf 
end-do 



116 



5. CHARACTER SEARCH 



The variables used In this algorithm are; 



SRCHSTR ; 

SRCHLNGTH : 
SRCHARG ; 
ARGLNGTH ! 
LOC t 
WORK ; 



pointer to a string of characters 

to be searched, 

length of that string, 

pointer to a string of characters, 

length of that string, 

an Integer return code, 

pointer to any needed storage. 



procedure CHARSRCHC SRCHSTR, SRCHLHGTH, 

SRCHARG, ARGLNGTH, LOC, WORK) 



Integer I 



LOC := 1 

do for all I such that 0<= I <= SRCHLNGTH-SRCHARG 

or until LOC <> -1 

if the substring of SRCHSTR from I to 

I+ARGLNGTH-1 = SRCHARG 

then LOC ;= I 

end-if 

end-do 



6, BIT TEST, SET, OR RESET 
The variables used are: 



F : Function code, l=test, 2 - set, 3= reset, 

N : Relative bit to be tested, 

Al: Pointer to tightly packed bit string. 

RC: Return code indicating original bit status, 
WORK; Pointer to any needed work storage, 

procedure bittest(f,n, ai ,rc,work) 

Integer ABIT,D 

ABIT ;s Al + N/Cword length) 

D := N mod (word length) 

if D'th bit at address ABIT = 1 
then RC ;= 1 
else RC ;= 0 
end-if 
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if F = 2 

then D'th bit at address ABIT ;= 1 
else if F = 3 

then D'th bit at address ABIT ;= 0 
end-lf 

end-lf 



7, RUNGE-KUTTA INTEGRATION 

This algorithm solves the differential equation F(t,y) = 
t-t-y = dy/dt using a third order Runge- Kutta integration. 
The variables used are: 



TO ! Initial value ot T, single precision, 

YO ; Initial value of Y, single precision, 

H : Interval of integration, single precision, 
TMAX: Final value of T, single precision, 

YMAX; Final value of Y returned, single oreclsion, 

procedure RUNGEKUTTACTO, YO, TMAX, Y max, WORK) 
rea 1 Ki , K2 , K3 

YMiX ;= YO 

do for all T from TO Incrmented in steps of H 

until T > TMAX 

Kl := H»CT+YMAX) 

K2 ;= H»(T + H/2 + Y + Kl/2) 

K3 := H * (T + 3*H/4 + Y + 3»K2/4) 

YMAX ;= YMAX + 2*Kl/9 + K2/3 ♦ 4^K3/9 
end*>do 



8, LINKED LIST INSERTION 

This algorithm inserts an element into a doubly llnKed 

list. Variables used are: 

LISTCB : Pointer to a list control block 
containing : 

HEAD: pointer to first node, 

TAIL: pointer to last node, 

NUMEMTRIES : number of entries, 

NEWENTRY: pointer to new entry to be Inserted, 
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procedure LISTIN5ERT(LISTCB,NEWENTRY) 

"the notation POINTER, FIELD Is used to access a 
particular field of the structure ponted to by 
POINTER" 

pointer PRESENT 
If LISTCP.NUMENTRIES = 0 

then "list Is empty, so Initialize" 

LISTCB.HEAD ;= LISTCB.TAIL ;= NEWENTRY 

LISTCB.NUXENTRIES := 1 

NEWENTRY. NEXT := NEWENTRY . PREV ;= 0 

else 

"list not empty" 

PRESENT := LISTCB.HEAD 

LISTCB.NUHENTRIES ;= LISTCB, NUMENTRIES + 1 
"determine position of new entry" 
while MEW. KEY >= PRESENT. NEXT <> 0 do 
PRESENT := PRESENT. NEXT 
if PRESENT. PREV = 0 and NEW. KEY < PRESENT. KEY 
then 

"new list head" 

LISTCB.HEAD := NEW 
NEW. PREV := 0 
PRESENT. PREV ;= NEW 
NEW, NEXT := PRESENT 
else 

If NEW. KEY => PRESENT. KEY 
then 

"new list tall" 

PRESENT. NEXT ;= LISTCB.TAIL ;= NEW 
NEW. NEXT := 0 
NEW. PREV := PRESENT 
else 

"insert in middle" 

NEW. NEXT := present 

NEW. PREV != PRESENT. PREV 

PRESENT, PREV ;= NEW 

"back up and llnK with predecessor" 

PRESENT != MEW, PREV 
PRESENT, NEXT := NEW 
end-if 
end" 1 f. 
end-if 
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9. QUICKSORT 



This algorithm performs a quicksort on an array of 
records. The variable used are; 



N ; The number of records to be sorted, 

M : Integer oarameter specifying the changeover 

point between quicksort and a simple Insertion, 
REC ; Pointer or the first element of the 
array to be sorted, 

WORK; Dointer to any needed working storage, 

procedure QUICKSORT ( N , REC , M , WORK) 

Integer L,R,I,J,K 

integer array ST^^CK CO ; 2»f (N ) -i ] 

character string V 

RECCN+l] ;= infinite 
L ;= 1? R ;= N 

do forever 

I ;= L; J;= R+1 ; V ;= RECCL) 
do forever 

do I ;= I+l until RECCI] => V end-do 
do J;=J-1 until RECCJ3 <= v end-do 
If J> I 

then swap RECCI) with RECCJJ 
else goto end-first 
end-lf 
end-do 
end-first; 

swap RECCL) with RECCJ] 

if both subfile sizes CJ-L ahd R-J) <= M 
then 

if stack empty 

then goto end-outer 
else poD L and R from stack 
end if 
else 

If smaller subfile size <= M 

then set L and R to lower and upper 
limits of larger supfile 
else push lower and upper limits of 
larger subfile onto stack 
set L and R to limits of smaller 
subfile 

end-if 
end-if 
end-do 
end-outer : 
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do for I from N-l to 1 In seps of 1 
if PECCI) > RECI + n then 
V ;= REC tl ] t J :=I + 1 
do forever 

REC[J-n := RECCJ] ; J ;=J+1 
if REC[J3 => V then goto end-last end-lf 
end-do 

end-last: ACJ-13 := V 
end- 1 f 
end-do 



10, ASCII TO FLOATING POINT CONVERSION 

The following variables are used in this algorithm; 



N : Number of characters In the string, 

A1 : Address of the character string, 

A2 : Address of floating ootnt number where the 
result will be placed. 

procedure AFP(N,A1,A2) 

integer NUMBER, POSITION 
real RESULT, DIVISOR 
boolean ISNEGATIVE 

ISNEGATIVE ;= false 
POSITION ;= 0 

If first character of Ai is a sign character 
then 

if sign character is 

then ISNEGATIVE ;= true 
end-lf 

POSITION := 1 
end-lf 

NUMBER ;= integer eoulvalent of characters 
POSITION to J-1 Of Al where 
character J of Al is ” 

RESULT ;= floating point equivalent of 
NUMBER 

" the following two steos can be done in 
parallel If desired" 

NUMBER :s integer eoulvalent of characters J+1 
to N of Al 

DIVISOR := floating eoulvalent of 10»»(N-J) 

A2 := result + (floating point equivalent of 

NUMBER) / DIVISOR 
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11. BOOLEAN MATRIX TRANSPOSE 



The following variables were used in this algorithm; 

A1 ; Pointer to a word of storage. 

A2 : bit number within word Al where 
the matrix begins, 

N : Size of the boolean matrix. 

procedure B?^T(N, Al , A25 
Integer T^J 

boolean BC1:N,1;N3 beginning at bit A2 of word Al 
do for all I and J such that (i<= J <= N) 

and (J+1 <= I <= N) 

swap 3CI,J] and 3CJ,I] 
end-do 



12. VIRTUAL MEMORY SPACE EXCHANGE 

This algorithm performed a virtual memory space exchange 
through the use of a suoervisor call. There are two 
functions which must be orovided by the algorithm. 



1, CALL; saves enough information to restore the en- 
tire state of the caller. 

2. RETURN; restores the environment active before 
the previous call. 



The sixteen benchmark proarams written by the second CFA 
study group follow, a complete discussion of them can be 
found in reference 1, 



1. terminal input driver 



This aloorithm inputs one 


line of ASCII 


characters 


from 


a terminal 


device , 


ASCII 


rubouts should 


delete 


the 


character, A 


carriage 


return 


terminates 


the 


line. 


The 


prooram need 


not be re 


entrant , 
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Algorithm: A subroutine TTYIN (BUFFER) initiates the 
transfer. It has a single reference parameter, the 
buffer to be filled. The buffer consists of: 

ADDRESS TERMADDR 

CHARACTER CBUFCl:?] 

The buffer is assumed to be large enough for the 
line. The transfer is started and the routine re- 
turns, The Interruot service routine collects the 
line in some machine dependent manner. The terminal 
interface is assumed to oe a minimal one, (it does 
the serial-oarallel conversion). When a carriage re- 
turn is entered, the terminal input is disconnected 
and a transfer to the buffer TERMADDR is made. 



2. MESSAGE BUFFERING AND TRANSMISSION 

This algorithm queues a message buffer and 
transmits the message over a Oma link in FIFO order. 



RECORD BUFRCADDRESS NEXT, ADDRESS TERMADDR, 

INTEGER SIZE, INTEGER DATA C 1 .* S I ZE 3 ) ; 
POINTER BUFR END, START 
ADDRESS TEMP; 

IQUEUE SUBROUTINE 

PROCEDURE QUEUECREFERENCE BUFFER)= 

BEGIN 

IF START NEO 0 THEN END, NEXT <- ADDRESS C BUFFER ) FI; 
END <- ADDRESS ( BUFFER ) ; 

JOUIT IF CHANNEL ALREADY RUNNING 
IF START NEO 0 THEN RETURN 
ELSE 

START <- ADDRESS(BUFFSR) ; 

TEMP <- 0; 

GOTO RESTART 
FI; 

END; 

INTERRUPT: 

BEGIN 

I 



then 
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i Programmers should insert here device and 
I machine dependent code to terminate the 
I device transfer 
TEMP <- STAPT.TERMADDR; 

START <- START, NEXT; 

restart: 

IF START = 0 
THEN 

GO TO TEMP 
ELSE 

i Programmers should Insert here device and 
! machine deoendent code to initiate the 
1 device transfer, 

FI; 

IF TEMP = 0 
THEN RETURN 
ELSE GO TO TEMP 
FI 
END 



3. MULTIPLE PRIORITY INTERRUPT HANDLER 

This test program is desioned to orocess interrupts from 
four devices in priority order. Upon receiving an interrupt, 
the processor will branch to the appropriate device service 
routine. All interrupts from lower priority devices will be 
disabled. Device priority is equal to device number, device 
number l has lowest priority, device 4 has highest. After 
the device dependent service the device ID is added to the 
executive queue for user scheduling purposes. This program 
need not be reentrant. Each device service routine will be 
simulated by the algorithm below, 

IDEVICE SERVICE ROUTINE INTEGER OWN A; FOR I <= 1 TO 
AC0!2] do a <- (A»899) MOD 123757 OD; 
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4. VIRTUAL MEMORY SPACE EXCHANGE 

This algorithm will involve a supervisory call handler 
which will provide the functions ’’call" and ’’return”. The 
supervisor is to implement protected procedure calls with 
parameters, "call" will select index into a table of address 
space descriptors maintained by the supervisor. The "call" 
performs the following: 

1. Save the caller's state. 

2. Determine the callee's address space, 

3. Set up the memory mapping and protection to ac- 
cess the callee's address space. 

The "return" function takes no parameters. It re- 
stores the environment active before the previous 
call. 



5. SCALE VECTOR DISPLAY 

This algorithm scales a list of graphic vectors about a 
given center. The vectors are represented as: 



function 4 bits 

X coordinate 12 bits 

intensity 4 bits 

y coordinate 12 bits 

PROCEDURE SCALEADJUSTCREF DLIST, VALUE LEN , 

VALUE XCENTR, VALUE YCENTR, 
VALUE SCALE)= 

BEGIN 

!0 LEO XCENTR, YCENTR LEO 2047 

JSCALE IS THE ACTUAL SCALE FACTOR TIMES 129 

INTEGER LEN, XCENTR, YCENTR, SCALE, I ,XTM?,YTMP; 

RECORD VECT0RCINT4 FUNCT,INT 12 X, INT4 INTEN, 

INT 12 Y); 

VECTOR DLISTCl :LEN] ? 

FOR I <- 1 TO LEN DO 
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XTMP <- DLIST.XCI] ♦SCALE; 

YTMP <- DLIST.YCI] ♦SCALE; 

IF DLIST.FUNCTCI] NEQ 0 
THEN 

XTMp <- XTMP+XCENTR^C128-SCALE) ; 
YTEMP <- YTEMP + YCENTR^C 128-SCALE) ; 
FI ' 

DLIST.Xm <- XTMP/128; 

DLIST,Y[I) <- YTMP/128; 

OD; 

RETURN 

END 



6. ARRAY MANIPULATION - LU DECOMPOSITION 

This algorithm factors a square matrix into an upper and 
lower triangular matrix. 



LUDECOMPCREFEPENCE A, VALUE N)= 

BEGIN 

REAL ARRAY A tl ;N, 1 ;N] ; 

REAL MULT; 

integer DIAG, ROW, COL; 

FOR DIAG <=1, N-1 DO 
FOR ROW <= DIAG+1,N DO 

AtROW,DIAG]<- MULT<- A C ROW , DI AG ] / A CDI AG , Dl AG] 
FOR COL <= DIAG-H,N DO 
A CROW, COL 3 < = A CROW, COL) -MULT^A CDI AG, COL] 

OD 

OD 

OD 

END 



7. target TRACKING 

This algorithm taxes 
object and finds in a 
closest entry. 



the coordinates of an unknown 
table sorted by x coordinate the 



PROCEDURE TARGETCPEFERENCE TABLE, VALUE LEN, VALUE X 

VALUE Y, REF'='RENCE FOUND) = 

BEGIN 

INTEGER LEN, START, END, MID, UP, DOWN; 
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REAL MINDIST; 

ADDRESS FOUND 

RECORD TENTRYCREAL X, REAL Y, REAL DAT1,REAL DAT2); 
TENTRY TABLECl;LEN] 

START <- 1; END <- LEN; 

WHILE START <- END DO 
MID <- (STAPT+END)/2 
IF TABLE, XCMID] < X 
THEN 

START <- MID+1 
ELSE 

END <- MID 
FI 
OD; 

ICompute distance of nearest x entry 
MINDIST <- DIST(TABLECMID3 ,X,Y) ; 

FOUND <- ADDRESSCTABLECMID] ) ; 

Isearch neighborhood for a nearer entry 
UP <- MID+l; DOWN <- MID-1; 

WHILE UP>0 OR DOWN >0 DO 
IF UP>0 THEN CHECK(UP); UP<- UP +1 FI; 

IF DOWN >0 THEN CHECK(DOWN); DOWN<-DOWN-l FI; 

OD; 

RETURN; 

!Chec)c an individual entry against closest found 
PROCEDURE-MACRO CHECK(J) = 

BEGIN 

IF J<1 OR J>LEN or ABSdABLE.X CJ] -X) >= MINDIST 
THEN J <-0 ; RETURN FI; 

IF DISTCTABLECJ3 ,X, Y) < MINDIST 
THEN 

MINDIST <- DIST(TABLECJ3 ,X,Y) ; 

FOUND <- ADDRESSCTABLECJ] ) 

FI; 

RETURN 

END 

I DISTO is the metric defined in the problem 
END 



8. DIGITAL COMMUNICATIONS PROCESSING 

This algorithm is given a message with a header which 
contains the destination and connection ID, and places the 
message in the appropriate transmission line's output 
buffer . 
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PROCEDURE FORWARDCREFERENCE MSG) = 

BEGIN 

RECORD MESSAGECINT16 CID,INT16 DEST, INT16 SIZE 

CHARACTER MSG Cl:?]); 
BUFTABLECINTEGER CID, ADDRESS BUFFER); 

MESSAGE MSG? 

POINTER BUFTABLE LINE? 

EXTERNAL ADDRESS DESTABLE [ 1 ;?] ; 

[Find BUFFER table for destination line 
LINE <- DESTABLECMSG.DEST) ; 

IFind ring buffer for this connection 
I < « 1 ; 

WHILE LINE.CIDCI] NEQ MSG.CID 
DO I <- I + 1 OD; 

BUFFER <- LINE, BUFFER Cl] ; 
iCopy the message to the buffer 
MDVE(ADDRESSCMSG) , BUFFER /MSG, SIZE) ; 

RETURN 

END 



9, HASH TABLE SEARCH 

This program locates the position a key would occupy in 
a hash table, 

PROCEDURE HASHLOOKCREFEPENCE TABLE, VALUE SIZE, 

VALUE KEY, REFERENCE POSITION, 
REFERENCE FULL) s 

BEGIN 

ADDRESS POSITION 
INTEGER SIZE, KEY, CHECK; 

BOOLEAN FULL; 

RECORD TENTRYCINTEGER KEY, INTEGER DATA); 

TENTOY TABLECO;SIZE-n ? 

I Compute first place to look 
CHECK <- KEY MOD SIZE; 

FULL <- FALSE; 

FOR I <- 1 TO SIZE/2 DO 

IF TABLE. KEYCCHECK] = KEY OR TABLE . KEY CCHECK] = 0 
THEN 

POSITION <- ADDPESSCTABLE, KEY CCHECK] ) ; 

RETURN 

FI; 

CHECK <- (CHECK + I) MOD SIZE 
OD 

FULL <- TRUE 

RETURN 

END 
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10, LINKED LIST INSERTION 

This alqorlthrn Inserts a node in an ordered doubly 
linked list. 



PROCEDURE LISTINSERTCVALUE LISTCB, VALUE NEWENTRY)s 
BEGIN 

RECORD LCBCADDRESS HEAD, ADDRESS TAIL, 

INTEGER NUMENTRIES); 

RECORD LISTEMTRYC INT32 KEY, ADDRESS NEXT, ADDRESS PREV) 
POINTER LCR LISTCB; 

POINTER LISTENTRY, NEWENTRY , PRESENT ; 

IF LISTCB, NUMENTRIES = 0 
THEN 

LISTCB, HEAD <• LISTCB, TAIL <- NEWENTRY; 

LISTCB. NUMENTRIES <- 1; 

NEWENTRY. NEXT <- NEWENTRY , PREV <- 0 
ELSE 

PRESENT <- LISTCB. HEAD; 

LISTCB, NUMENTRIES <- L ISTCB , NUMENTRIES+ 1 ; 

WHILE NEWENTRY, KEY GEO PRESENT. KEY AND 

PRESENT, NEXT NEQ 0 
DO PRESENT <- PRESENT. NEXT OD; 

IF PRESENT. PREV =0 AND NEWENTRY. KEY < PRESENT. KEY 
THEN 

LISTCB, HEAD <- NEWENTRY; 

NEWENTRY. PREV <- 0; 
present, PREV <- NEWENTRY 
NEWENTRY. next <- PRESENT; 

ELSE 

IF NEWENTRY. KEY GEO PRESENT, KEY 
THEN 

PRESENT, NEXT <- LISTCB. TAIL <- NEWENTRY; 

NEWENTRY. NEXT <- 0; 

NEWENTRY. PREV <- PRESENT 
ELSE 

NEWENTRY, NEXT <- PRESENT; 

NEWENTRY, PREV <- PRESENT . PREV ; 

PRESENT. PREV <- NEWENTRY; 

PRESENT <- NEWENTRY. PREV; 

PRESENT. NEXT <- NEWENTRY 
FI 
FI 
FI 

RETURN 

END 
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11. PRESORT ON A LARGE ADDRESS SPACE 



This algorithm takes an array of records In random 
order and rearranges them to form a heap. The heap Is a 
binary tree in which each node Is greater than or equal to 
its descendants. 



HEAFIEYCRSf ERENCE REC, VALUE N') = 

BEGIN 

INTEGER ARRAY RECCl :N] ; 

INTEGER CHECK, NEW; 

FOR NEW <- 2, N DO 
CHECK <- NEW; 

WHILE CHECK NEO 1 AND RECCCHECK] > RECCCHECK/2] 
DO 

RECCCHECK] <=> RECCCHECK/2]; 

CHECK <- CHECK/2 
OD 
OD 
END 



12. AUTOCORRELATE ON A LARGE ADDRESS SPACE 

This algorithm computes the autocorrelation of the 
vector A from l to T, 



PROCEDURE AUTDCREFERENCE A, VALUE N, VALUE T, 

REFERENCE PES)= 

BEGIN 

INTEGER N,T,TAU; 

REAL A Cl ;N] , RES Cl :T] ; 

FOR I <- 1 TO T DO RESCI] <- 0 OD; 

FOR I <- 1 TO N DO 
FOR TAU <- 1 TO T DO 

IF I + TAU-1 > N THEN EXITLOOP FI; 
RESCTAU] <- RESCTAU] -► A C I ] * A C I + TAU- 1 ] ; 
OD 
OD 

RETURN 

END 
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13. CHARACTER SEARCH 



This algorithm searches a given string to see if It 
contains a substring that exactly matches the given argument 
string. 



PROCEDURE CHARSRCHCREF SRCHSTR, VALUE SRCHLNGTH, 

REF SPCHARG, VALUE APGLNGTH,REF LOC)= 

BEGIN 

INTEGER I,SRCHLNGTH, ARGLNGTH; 

BYTEVECTOR SRCHSTR C 0 ; SRCHLNGTH- 1 ] , SRCHARG C 0 ; ARGLNGTH- 1 ] 
LOC <- - 1 ; 

IF ARGLNGTH LEO 0 THEN LOC <- 0; RETURN FI; 

FOR I IN 0,SRCHLNGTH-ARGLNGTH DO 

IF SRCHSTR tl/IfARGLNGTH] LEO SRCHARG 
THEN LOC <- l; RETURN FI; 

OD; 

RETURN 

END 



14. BOOLEAN MATRIX TRANSPOSE 

This algorithm computes the transpose of a given N by N 
matrix In place. 



PROCEDURE BMTCVAL N,VAL Al, VAL A2) = 
BEGIN 

integer I,j; 

BOOLEAN bci:n,i:n] 

FOR I IN 1,N-1 ; J IN I+1,N DO 
8CI,J] <=> BCJ,I3 
DD 

RETURN 

END 
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15. RECORD UNPACKING 



This algorithn unpacks the fields of a record into an 
integer array. 



PROCEDURE UNPACK(REF RECORD, REF FORMAT, VALUE LEN 

REF RESULT)= 

BEGIN 

BITSTRING RECORDCO:?]; 

INTEGER LEN,START,RESULTC1 ;LEN] , TEMP, I; 

ARBTYPE FORMAT Cl : LEN 3 ; 

START <- 0 

FOR I <- 1 TO LEN DO 

TEMP <- PEC0RDC3TART!START + F0RMATCI3-13 ; 

START START + FORMATCT3; 

IF FORMATCI] IS A DISTINGUISHED VALUE 
THEN 

TEMP <- SIGNNEXTENDCTEMP) 

Fl; 

RESULT CI3 <- TEMP; 

OD; 

RETURN 

END 



16, VECTOR TO SCAN LINE CONVERSION 

This algorithm takes a list of vectors and produces a 
raster scan line conversion. 



PROCEDURE VECSCANCREF DLIST, VALUE LEN, REF TEMP)= 

BEGIN 

RECORD DISPLAYCINT16 XS, INT16 YS, INT16 XE, INT16 YE), 
WORKLIST(INT16 XS,INT16 XE,INT32 Y,INT32 SLOPE); 
DISPLAY DLISTflJLEN] 

WORKLIST TEMPCl ;LEN + 1] ; 

INTEGER I, START, LINE, DENOM; 

BITSTPING BIT Cl ! 10243 ; 

IGenerate working vector 
FOR I <- 1 TO LEN DO 

TEMP.XSCI3 <- DLIST. XSCI3; 

TEMP.XE <- DLIST. XECI3; 

TEMP.YCI3 <- DLIST. YS CI3 ♦1024; 

DENOM <- (DLIST. XECI3 - DLIST. XSCI3 + 1); 
TEMP.SLOPECI3 <- ( DLIST . YE C 1 3 -DLIST . YS C 1 3 ) ♦ 1 0 2 4/DENOM 



132 



□ D; 

TEMP.XSCLEN+l] <- 1025 
1 Generate the scan image 
START <- l; 

FOR LINE <- 1 TO 1024 DC 
BIT <- 0 
I <- START; 

WHILE TEMP.XStn LEQ LINE DO 
FOR K <- TEMP.YCI3/1024 TO CTEMP.YII] + 

TEMP.SLOPECI] )/1024 

DO BITCK] <- 1 OD; 

TEMP.YCI] <- TEMP.YCI] + TEMP . SLOPE C I ] ; 

IF TEMP.XECI] = LINE 

THEN TEMP [START] < = > TEMP Cl] ; 

START <- START + 1; 

FI; 

I <- I + l; 

OD? 

OD 

RETURN 

END 
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APPENDIX E 



CDS 432/670 USERS MANUAL 

The following is an effort to enable someone with no 
prior knowledge of the 432/600 system to be able to compile, 
link, and execute programs on the 432 in a minimum amount of 
time and 'fuss', A knowledge of ADA Is assumed, as is 
familiarity with VMS (e.g, the VMS editor). 



Referring back to 


Flgure[61 it 


can 


be seen that 


a 


variety of hardware 


and 


software 


Is 


Involved in simply 


getting a program to 


'run ' 


on the 


432, 


This variety 


of 



needed hardware/software is collectively referred to as the 
432 "Cross Development System", or "CDS" for short. Not 
surprisingly, those functions needed first in order to 
achieve the desired result of a program executing on the 432 
are accomplished on the VAX 11/790 host. Briefly, the steps 
reaulred ,Dius their CDS 'companion elements' are: 

1. Program Creation/Editing -- VAX/VMS 

2. Compilation -- VAX/VMS 

3. Linking -- vax/vms 

4. Downloading -- MDS 800 

5. Program Load/Execution -- MDS 800/432 
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1, PROGRAM CREATION/EDITING 

Creation of a login file with at least the following 
commands will substantially add to the ease of your terminal 
sessions while worklno with those CDS parts which reside on 
the VAX/VMS host; 

SADA432 

$moPo : == del ♦. mso mbo ; 

$mopc ;== del ♦,msc;»+*,mbc;* 

smope :== del »,mse;<‘ + *,mbe;» 

The reason for these commands will become evident as we 
continue , 

ADA source files to be compiled by the Intel ADA cross 
compiler must have a file extension type of either: 

1. <filename>, MSS => An ADA source specification 
file. 

2. <f llename>, MBS => An ADA source body file, 

3 . <f llename> ,MCS => Both specification and body. 

In our opinion, dividing source code into separate 
specification C.msS) and body (.MBS) files was in keeping 
with some of the original philosophies behind ADA, l.e., 
encapsulation and information hiding. Unfortunately, the 
compilation efforts, of necessity, must double (2 files to 
compile vs, 1 in the vcs case). What follows next are 
figures of a sample program. Figure 19 Illustrates the 
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division into specification and body. Figure 20 Illustrates 
the combined (MCS) format. Besides the distinction of 
working with two separate files as opposed to one, take 
special note of the line, common to the 'body', which begins 
with "pragma environment,,,". 



package EXAMPLEl is 
procedure SIMPLE? 
end EXAMPLEl? 



I The specification filed as EXAMPLEl, MSS 

I The body filed as EXAMPLEl, MBS | 

V V 

pragma environment ( "ACS : TEXTIO , MLE" , "EXAMPLEl , MSE" , 

"INTIO.MSE" ) ? 

with text«io, Intlo; 
use text-io, intlo, ascii? 

Package body EXAMPLEl is 
procedure SIMPLE is 

m m 

x,y,z ! Integer; 

Begin 

X : = 10? 

y := 15; 

put-line. 10( " SIMPLE ")? 
out(bel) ? 

-- this rings the bell, 'use ascii 'enables this 
z := x+y? 

put(z); -- 'Intlo' allows you to do this 
put (bel ) ? 

put-llne-lOC'END SIMPLE"); 
end SIMPLE; 
end EXAMPLEl? 



Figure 19. Specification and Body Format (Separate) 
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pragma environment C ACS rTEXTIO.MLE" INTIO. MSE” ) ? 
with text.lo, Intlo; 
use text«io ♦ Intlo ? 

oackage EXAMPLE2 Is 
procedure SUPPLE; 
end EXAMPLE2; 



package body EXAMPLE2 Is 
orocedure SIMPLE is 

m 

x,y,z : integer; 



Begin 

X ; = 10; 

y * - 15; 

put-line. 10( » SIMPLE "); 
out (bel ) ; 
z :s x+y; 
put (z) ; 

Put-line-lOC'END SIMPLE”); 
end SIMPLE; 
end EXA.MPLE2; 



Combined specification and body filed as 
EXAMPLE2.MCS. 



Figure 20, A Combined Format Example 



Information is conveyed to the ADA compiler system by 
means of pragmas. The environment oragma specifies the names 
of external environment files Cor library units) that 
constitute the compilation environment for the current 
compilation unlt(s). If the current compilation depends on 
other compilation units from other compilations, then the 
environment files from these compilations must be listed in 
the ENVIPONMENT pragma in the current compilation. These 



137 



environment pragmas enable separate compilation while still 
maintaining strong type checking of interfaces, two features 
which ADA is supposed to fulfill. In these examples the 
compilation of the body depends on; 

-- ACS:TEXTIO,MLE => SO the package can perform 
character I/O, 

-- INTIO.MSE => SO the package can perform Integer 
I/O. 

EXAMPLEl.MSE => the corresponding specification 
file. 



To alleviate confusion on file extensions, the following 
is a list of VMS file extensions used in the 432 ADA 
Compiler System (ACS), 



1. First character: 



M -- The file contains 
for module, 

S -- The file contains 

2. Second Character; 

S -- The file contains 
tion, 

B -- The file contains 



a Horary unit, M stands 
a SEPARATE stub. 

a program unit speciflca- 
a program unit body. 



C -- The file contains the combination of a pro- 
gram unit specification and a prooram unit 
body. 



L -- The file is a program Horary file supplied 
by Intel. 



3. Third Clast) Character: 



S -- The file is an ADA source text file. 
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E -- The file Is an environment file, 

R -- The file is a REPORT file. 

0 -- The file is an object code (EOD) file, 

L — The file is a REPORT listing file, 

C -- The file is an object code listing file, 

M -- The file is a specification file for the 

COMBINE utility and contains a list of en- 
vironment files that are to be meraed. 

1 -- The file is an Integrated environment file 

created by the COMBINE utility. 

T -- The file is a listing file produced by COM- 
BINE and contains the file table listing of 

the integrated environment. 



For added clarification; 



e.q, <f ilename> ,MSS -- An ADA source text file 
which corresponds to a specification, 

e.g. <f llename> , MBS -- An ADA source file contain- 
ing program unit bodies, 

e.g, TEXTIO,MLE -- A library environment file sup- 
plied by Intel. 



2. COMPILATION ^ 

The Intel compiler is invoked by the command 
"IDA", followed by the filename. If the filename is 
omitted, the compiler will prompt for it. Our input to the 
compiler consisted either of <f I lename , MSS> , for 
specification files, or <fliename,MBS>, for the 
implementation, l,e., body, files. Output from a successful 
compilation consists of files of type: 
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1, ,MBE or ,MSE -- The environment file represen- 

tation, 

2, ,MBC or ,MSC -- The object code listing file. 

It is utilized when debugging on the 432, 

3, .MBO or ,MSO -- The object code. This is input 

to the llnJcing orocess. 



Unsuccessful compilation results in files of the type; 



1, ,MBL or ,MSL -- A report listing file. We gen- 
erally never used this, 

2, ,iMBR or ,MSR -- A file which when prefixed by 
the command "REPORT", e,g,, REPORT prog.mbr, al- 
lows one to scan through one's program on the 
terminal. More importantly, all errors detected 
by the compiler are flagged with their 
corresponding diagnostic message. 



A typical session on VAX/VMS consists of the following; 



1, Code and compile the specification file for the 
problem, l.e,, the program, at hand. Since a 
specification file is essentially just a means of 
formalizing in ADA what one considers the inter- 
face to be, it usually needs no environment prag- 
ma statement, 

2, Code and compile the body, which is the means by 
which one implements the program. Since the body 
depends on what the Interface is, the environment 
file representation of the corresponding specifi- 
cation file must be Included. Additionally, if 
I/O is to be performed in the body, which is gen- 
erally the case, the general I/O, Intel-supplied 
package (TEXTIO), must also be included in the 
pragma environment statement. 



An example of all this can be found in Appendix C, which 
shows the ADA source code for the programs done in this 
thesis. 
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In case It wasn't made clear In the above discussions, 
compilation order is important. Any modules included in the 
pragma environment statement or referenced in the standard 
ADA constructs, "WITH..." and "USE,,,” must be successfully 
compiled beforehand, otherwise unsuccessful comollation is 
all the reward one will get for one's efforts in the current 
compilation attempt. 

Successful comollation means the creation of three new 
files in addition to the original source file. Directory 
space in VMS is quickly exhausted if one is performing many 
compilations, without adequate directory space, the INTEL 
compiler and linker will abort. Therefore, when asking for 
an account, the system managers must be Informed that more 
directory space than is normally given a VMS user is needed. 
Furthermore, in an attempt to provide a quick means of 
deleting unneeded environment, object-code listing, and 
object-code files, the commands, mope, mope, and mopo will 
automatically delete all files of the corresponding flletyoe 
in the current directory. 

Once one has successfully defined one's interface, coded 
it, compiled it, and has done the same with the 
corresponding body or bodies, one has reached the point 
where in most traditional systems one is ready to link the 
object code in preparation for actual program execution. In 
the 432 case, additional compilation must still be performed 
before the linking process may begin. 
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First, a module termed PSERP.MBS must be compiled. An 
example of this is included in Appendix C, Its function is 
to initialize the user process(es). It essentially marks 
which module is to begin execution first. For instance, a 
Driver routine which Invokes all other subroutines is 
usually executed first. In our case, PSERP always 
initialized the Driver routine, which we always termed MAIN, 
in an attempt to cut down on our coding/compilaticn efforts. 

Secondly, as pointed out in the architecture overview on 
operating system support, users can tailor some of the iMAX 
O.S. packages. In this thesis, modification of the system 
configuration package, PSORS . MBS , was implemented. Hence, the 
successful compilation of this modified package was also 
needed. This package is also included in Appendix C. 

3. LINKING 

The .MSO or .MBO files produced by a successful 
compilation are input to the 432 linker by being listed in a 
user created directives file. The output from a successful 
link is of flletype .EOD. EOD stands for "External Object 
Description". Actually, the respective MSO and mbo output 
files from the compiler are in this EOD format. The choice 
of using EOD as the flletype of the output from the linker 
is an arbitrary one. 

The 432 linker combines a set of compiled EOD's (e.q. 
the ,MSO and ,M50 files) into a single linked EOD, Compiled 
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EOD's, generated by the ACS, contain program modules. These 
modules. In turn, contain a collection of compiler-generated 
objects, such as segments, refinements, etc. The output from 
the linking process, a single file. Is then downloaded to 
the MDS 800 system. 

The 432 linker performs the following traditional 
functions : 

1, Resolves Inter-module references, 

2, Assigns physical memory addresses to all segments 
contained in the Input modules, 

3, Verifies the compatibility of modules that are 
linked together. 

4, Produces a linked EDO that may be loaded Into the 
System 432/670 main memory and executed, 

5, Generates error messages for abnormal conditions 
encountered during processing, 

6, Generates a linker listing that summarizes the 
results of the linker operation and address as- 
signment. 



In addition, the linker performs the following 432-speclfic 
actions ; 



1, Version checks the input ECDs for compatlolllty , 

2, Assigns object table directory Indices and object 
table Indices (known as object coordinates) for 
objects contained within the input modules. 

3, Builds the physical 432 access segments described 
symbolically within each Input module, 

4, Builds object tables and the object table direc- 
tory associated with the objects In the Input 
modules . 
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5, Generates initialization object tables, access 
descriptors, and storage allocation information. 

The net result of all this is an EOD which, when loaded 
into 432 memory, will execute as one has programmed it. 

The input or directives file to the 432 linker should be 
a file created on VMS with a file extension of LKD, This 
file, an example of which is provided in Figure 21, may have 
other file extensions or types. However, if that is the 
case, then the full file name must be given to the linker, 
i,e,, LKD is the default file type. For example, given a 
link file which we call **TEST,LKD% to link this file, the 
following command would be entered: 

LINK432 TEST 

The linking process can be appreciably longer than 
compilation. However, if linkage is successful, a single, 
simple message of: 

LINKAGE SUCCESSFUL 

should be the only message which appears on the console. 
Warning messages, not error messages, accompanied by 
"LINKAGE SUCCESSFUL", do not really mean a successful 
linkage! At least this has been true in our experience, A 
detailed explanation of the different directives which can 
appear in the linker file, plus their meanings, can be found 
in the manual, "VAX/VMS Host User's Guide", With the 
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culmination of a successful liniclng# one is ready to 
download the output file generated by the linker to the MD5 
800 system. For a detailed explanation of the linking 
process and the available direct ives , 1 ,e , , commands Included 
in the link file, refer to "VAX/vms Host User's Guide". 



; An examole of a link file which serves as Inout 
; to the 432 linker. The semicolons which precede 
;These statements signify comments. Link, free, 

; output, print, and objectmap are examples of 
; linker directives. The blank lines which occur 
; between directives MUST be present! 

link ACS! IMAXvl ,eod 
ACS!textlo,mlo 
examplel , mso 
examplel . mbo 
main , mso 
main , moo 
pserp. mbo 
osors.mbo 

freed In directory) 

output example, eod 

print example, map 
objectmap 

This could be filed In VMS as TEST.LKD 



rioure 21, A Linker Input File 



4. DOWNLOADING 

Downloading is performed on the MDS 800 system. In 
order for downloading to be accomplished, the VAX must be 
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operating under V^’S, A cable, marl<ed with a tag which reads 
"VAX", is the transmission facility for downloading. The 
following steps comprise the Procedure to follow when 
downloading a file; 



1, Attach the VAX cable to the ADM36 terminal. Logon 
to VMS as you normally would. Enter the following 
command ; "SET TERM/SPEEO=2400" , This is done be- 
cause the MDS 800 system Is currently modified to 
suDoort only 2400 baud communication rates unless 
hardware/software changes are implemented, 

2, Remove the VAX cable from the ADM terminal, con- 
nect one end to a null modem. Connect the other 
end of the null modem to the MDS 800 TTY port lo- 
cated on the control unit, 

3, Insert into drive 0 of the MDS 800 system the 
ASYNCH LINK diskette, 

4, Insert into drive 1 the diskette one wishes to 
download to. Boot the system. 

5, On the MDS 800 terminal, enter the following com- 

mand : "DNLOAD <VMS EOD flle> TO :Fi:<new or same 
file name>. For instance, assume one nas an EOD 
file named TEST.EDD in the VMS directory. Furth- 
ermore, one wishes to call this file TESTl.EOD on 
the MDS 800 system. One would enter the following 
command; "DNLOAD TEST. EOD TO 

; FI ; TESTl . EOD" , quotes not included. 



we have experienced average download times of 
approximately 20 minutes. Any errors in transmission mean 
that downloading must be redone until a complete error-free 
download is accomplished. We have not experienced any errors 
in downloading to date. The conclusion of a successful 
download marks the beginning of the next step, execution on 
the 432, 
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5. PROGRAM LOAD/EXECUTION 



Now that a linked EOD file Is on a diskette, all that 
remains Is to load it into 432 memory and execute it. The 
following procedure assumes that the MDS 800 system and the 
432/670 execution vehicle are powered up and have no 
hardware faults. In the following discussion, commands which 
are to be entered at the MOS 800 terminal (termed the 
"debugger console" by INTEL) will be printed In capital 
letters and enclosed in quotes. This Is for illustration 
purposes only. Capital letters are not necessary, and quotes 
will result in an error message. 



1. Insert into drive 0 of the MDS 800 system, the 
diskette labeled UPDATE-432/DE8UG-432 , 

2. Insert into drive 1 the diskette which contains 
the executable program. Boot the system, 

3. Enter the following command; "RUN WORK :F0;". 

4. When the ISIS prompt C-) returns, enter: "RUN 

DEB432". This Should result in the display of 
"SERIES III 432 Systems Level Debugger, vi.OO", 

5. Once 'in the debugger' the ISIS prompt will be 
replaced by a "?" as the prompt symbol. Enter the 
command: "INIT", 

6. When the prompt returns, enter: "INCLUDE 

DE8432.TEM" . 

7. When the prompt returns, enter: "DEBUG ;Fl:< 

filename. flletype >". For example, suppose one 
has downloaded the file TEST, EOD which one wishes 
to execute. Here, one would enter; "DEBUG 
:F1 tTEST.EOD" . 

8. Enter: "START", This command initiates program 
execution . 
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This command will result in program execution on the 
432, For an in-depth explanation of debugging facilities 
available on the 432, in case the program does not execute 
as planned, refer to ”Workstation User's Guide”, 
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